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CHAPTER    1 
INTRODUCTION:    PROBLEM  IDENTIFICATION    AND  GOAL 


The  expansion  of  the  availability  of  mlcro-oomputers  in  primary 
and  secondary  institutions  has  created  an  interesting  probleo  for  the 
mathematics,  business,  and  science  teachers  In  American  schools.  As 
schools  have  begun  to  Implement  computer  science  programs  into  their 
eurrieulums,  it  usually  has  been  the  mathematics,  business,  or  science 
instructors  who  have  been  asked  to  teach  the  newly  created  courses  - 
often  without  the  benefit  of  much  formal  training  in  this  subject  much 
less  training  in  the  methods  and  concepts  of  how  best  to  teach  it.  To 
compound  this  problem  of  inexperience,  appropriate  textbooks  are  often 
unavailable.  Thus  the  average  instructor  of  computer  science  in  the 
public  schools  is  left  at  a  definite  disadvantage  as  be  or  she  prepares 
to  teach   the  subject  matter. 

I  faced  these  same  problems  four  years  ago  when  I  accepted  a 
full-time  Job  as  a  high  school  computer  science  instructor.  As  a  recent 
college  graduate  with  a  major  in  mathematics,  I  had  taken  computer  pro- 
gramming courses  but  no  courses  to  prepare  me  to  teach  in  this  subject 
area.  I  discovered  in  my  initial  experience  in  teaching  computer  sci- 
ence that  a  large  percentage  of  the  students  in  my  classes  failed  to 
grasp  the  overall  concept  of  programming.  This  failure  of  the  students 
reflected  my  inadequacy  in  teaching  formal  analytic  problem  solving. 
Briefly,  formal  analytic  problems  can  be  defined  as  those  problems 
where  the  preconditions  and  the  desired  postconditions  are  given,  and 
the  student  is  asked  to  define  the  translation  actions.  As  applied  to 
computer     programming,      the     student  is  given  the  input  description  and 
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tbe  desired  result,    and  he  or   she  Is  asked     to     generate     the     language 
Instructions  to  perform   the  translation. 

I  found  in  my  classes  that  if  I  gave  my  students  a  problem  where 
they  were  to  process  an  input  file  and  produce  a  report,  many  were 
unable  to  specify  the  problem  in  terms  of  tbe  basic  processing  confi- 
guration of  tbe  input  file,  internal  memory,  and  the  output  file.  In 
addition,  even  if  some  students  understood  the  problem  in  terms  of  this 
configuration,  many  were  unable  to  define  the  steps  at  the  language 
level  necessary  to  solve  the  problem  in  the  given  configuration.  This 
inadequacy  in  teaching  formal  analytic  problem  solving  became  the 
motivation  for   tbe  formulation  of   tbe  content   of   this  paper. 

As  a  high  school  instructor  I  formulated  a  structured  approach  for 
the  basic  high  school  computer  science  course  known  as  Computer  Science 
1  (hereinafter  referred  to  as  CS1)  designed  to  teach  my  high  school 
students  to  solve  formal  analytic  computer  science  problems.  Briefly, 
this  approach  was  designed  to  teach  to  specify  the  pre-  and  postcondi- 
tions in  terms  of  a  given  configuration,  to  abstract  a  solution  using 
aliened  actions  within  the  configuration,  and  to  implement  that 
abstraction  into  a  higb-level   language. 

In  developing  this  method  I  utilized  the  following  two  basic 
assumptions   : 


(1)  That  the  students  were  initially  unable  to     solve     formal 
analytic  problems  into  a  high-level   language, 

(2)  That  I  lacked  a   proper   approach   to  teach   the     student     to 
solve  analytic  problems. 
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Most  of  the  high  school  students  would  enroll  in  CS1  because  of 
interest,  not  because  they  plan  to  major  in  computer  science  in  col- 
lege. Thus  the  most  important  goal  in  the  proposed  structured  approach 
to  teaching  the  CSl  course  is  that  of  providing  the  student  with  an 
educational  experience  where  his  or  her  analytic  skills  are  developed, 
not  necessarily  that  of  teaching  the  students  the  intricacies  of  a  pro- 
gramming language. 

The  Association  for  Computing  Machinery  (hereinafter  referred  to 
as  ACM)  defines  the  following  major   objectives  for   CSl: 


to  introduce   a  disciplined     approach     to     problem- solving 
methods  and  algorithmic  development, 

to  introduce   procedural   and  data  abstraction. 

to  teach   program  design,    coding,    debugging,    testing,      and 
using  good  programming  style. 

to  teach  a  block-structured  high-level  language, 

to  provide  a  familiarity   with   the  evolution     of     computer 
hardware  and  software  technology. 

to  provide   a  foundation  for  further   studies     in     computer 
science.    [1] 


The  remainder  of  this  report  explains  a  possible  course  design  for 
CSl  that  I  developed  which  allows  the  above  objectives  to  be  met  and 
that  also  provides  a  defined  method  to  enhance  the  high  school 
student's  analytic  skills  in  computer  science.  Chapter  Two  defines 
what  is  meant  by  a  formal  analytic  problem.  Chapters  Three,  Four,  and 
Five  explain  the  three  basic  components  of  the  course  design,  as  fol- 
lOHs: 
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(1)  A  defined  problem  domain  to  be  used  In  the  creation  of 
analytic  problems  for   the  student   to  solve. 

(2)  A  synthetic  model  for  illustrating  analytic  solutions, 
for  use  as  a  student  development  model  and  for  providing 
a  formal   testing  format  for   analytic  problem   solving. 

(3)  Teaching  and  testing  in  terms  of  analytic  problem  solv- 
ing. 


Finally,    Chapter  Six  will   provide   conclusions  concerning  the     pro- 
posed course  design. 
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CHAPTER   2 
DEFINniON    OF  FORMAL    ANALmC  PROBLEM  SOLVHG 


The  goal  of  this  paper  Is  to  define  a  course  in  which  the  Intro- 
ductory students  can  enhance  their  abilities  to  specify  a  problem, 
abstractly  design  a  solution,  and  implement  that  design  into  a  high 
level  language.  In  other  words,  the  course  is  designed  to  develop  the 
students'  abilities  to  solve  formal  analytic  problems.  This  chapter 
provides  a  definition  of  formal   analytic  problems. 

2.1      Definitions  of  Formal   Analvtlc   Problems  and  Formal  Svnthetlc  Prob- 
lems 

There  are  two  basic  types  of  problems  that  can  arise  for  people  to 
solve  -  Informal  problass  and  formal  problems.  Computer  science  is 
concerned  with  the  solving  of  formal  problems,  "Formal  problems  are 
characterized  by  complete  specifications:  precisely  specified  initial 
oonditlons,  as  well  as  solutions  or  results  of  a  specified  form;  and 
they  must  be  solved  by  a  completely  specified  set  of  actions.  "[2]  From 
this  definition  is  derived  the  three  components  of  a  formal  problem  as 
follows:  1)  The  initial  conditions  C preconditions);  2)  the  desired 
result  (postconditions);  and  3)  the  actions  to  perform  the  translation 
(algorithm  or  program).  If  all  three  components  of  the  formal  problem 
are  specified,  then  a  complete  specification  of  the  problem  is  present. 
However,  when  one  of  the  three  necessary  components  is  missing,  we  have 
a  formal  problem  that  needs  solved.  Two  types  of  formal  problems  can 
be  created  depending  on  which  one  of  the  components  is  not  specified  - 
problems  of   synthesis  and  problems  of   analysis. 

In  problems  of  synthesis  the  student  is     given     the     preconditions 
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and  the  actions  to  obtain  the  desired  result.  The  student  normally 
knows  the  general  form  of  the  desired  result  but  using  the  precondi- 
tions must  perform  the  actions  to  instantiate  the  desired  result.  Fol- 
lowing a  cooking  recipe  involves  solving  a  problem  of  synthesis.  In 
computer  science,  for  example,  the  student  could  be  given  a  set  of  code 
(actions}  and  an  input  list  (preconditions)  for  that  code  to  process, 
and  the  student  is  then  asked  to  specify  the  output  (postconditions). 
One  method  to  be  used  in  solving  synthesis  problems  is  to  have  avail- 
able an  input  list,  an  empty  memory  area,  and  an  empty  output  area. 
The  student  then  executes  the  instructions  making  the  changes  to  the 
respective  areas.  The  resultant  solution  of  the  synthetic  problem  is 
the  state  of   the  output  file  at  the  termination  of   the  code. 

In  problems  of  analysis  the  student  is  given  the  preconditions  and 
the  desired  postconditions.  The  student  must  then  develop  the  actions 
to  make  the  translation  from  preconditions  to  postconditions.  An  exam- 
ple is  where  a  traveler  is  in  Manhattan,  Kansas  and  wants  to  drive  to 
HcCook,  Nebraska,  His  presence  in  Manhattan,  Kansas  is  the  precondi- 
tion, and  his  arrival  in  McCook,  Nebraska  is  the  desired  postcondition. 
The  goal  of  the  analytic  problem  is  to  derive  the  actions  to  make  the 
translation.  In  computer  science,  for  example,  the  student  is  given  a 
programming  problem  which  contains  the  input  description  (precondi- 
tions) and  desired  result  (postconditions),  and  the  student  is  asked  to 
derive  the  program  instructions  to  make   the  translation. 

Solving  a  formal  analytic  problem  depends  greatly  on  the  physical 
configuration     and     the     allowable     procedural   abilities.    For  instance. 
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using  the  trip  to  MoCook  example,  if  the  mode  of  transportation  is  a 
car,  the  physical  configuration  becomes  the  highway  system  and  the 
allc«able  procedural  actions  become  driving  down  a  highway  and  turning 
left  or  right.  However,  if  the  mode  of  transportation  is  an  airplane, 
the  physical  configuration  is  based  on  the  available  air  routes  and  the 
allowable  actions  are  ascent,  descent,  and  the  respective  turns  during 
the  flight. 
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CHAPTER   3 
DEFINED  PROBLEM  DOMAIN 


As  explained  in  the  introduction  to  this  paper,  students  in  CSl 
initially  have  trouble  specifying  a  problem,  abstracting  a  solution, 
and  implementing  the  solution  into  a  high-level  language  (i.e.,  formal 
analytic  problem  solving).  In  order  to  overcome  this  problem  for  the 
student,  the  first  component  necessary  for  the  teaching  of  formal  ana- 
lytic problem  solving  in  CSl  is  the  creation  of  a  defined  problem 
domain.  The  reason  for  creating  this  domain  is  that  in  solving  any  type 
of  problem,  not  only  computer  science  problems,  it  is  important  that 
the  students  understand  the  domain  or  environment  in  which  they  are 
being  asked  to  solve  the  problem.  For  example,  if  the  students  are 
asked  to  solve  the  analytic  problem  of  hou  to  travel  from  Manhattan, 
Kansas  to  McCook,  Nebraska,  they  understand  because  of  prior  experi- 
ences the  domain  or  environment  they  are  asked  work  within  if  the  the 
environment  includes  driving  a  car  on  the  highway  system.  But  a  major- 
ity of  the  students  probably  could  not  solve  the  problem  if  asked  to 
solve  it  within  an  environment  or  domain  that  Includes  the  use  of  an 
airplane  and  the  air  routes  because  of  their  lack  of  understanding  of 
this  configuration  and  the  allowable  actions  within  it.  Likewise  in  the 
teaching  of  CSl,  the  students  must  be  provided  with  a  domain  that  they 
understand  before  they  can  develop  solutions  to  problems  within  the 
domain. 

The  proposed  course  design  provides  a  defined  problem  domain  which 
consists  of  1)  a  physical  processing  configuration  (i.e.,  the  highway 
system  in  the  above  described  example)   and  2)     the     necessary     abstract 
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analytic  components  consisting  of  data  abstraction  (I.e.,  the  cities 
between  Manhattan  and  MoCook  and  the  highway  numbers  in  the  above 
described  example)  and  the  allowable  procedural  abilities  necessary  to 
process  within  the  configuration  (i.e.,  start  the  oar,  turn  left, 
accelerate,  stop,  etc.  in  the  above  described  example).  Before 
attempting  to  solve  analytic  problems  In  CSl,  the  student  must  become 
familiar  with  this  defined  problem  domain.  This  chapter  explains  and 
illustrates  the  physical  processing  configuration  and  the  necessary 
abstract  analytic  components  encompassing  the  defined  problem  domain. 

3.1    Physical  Processing  Configuration 

In  order  to  create  a  defined  problem  domain  within  which  the  stu- 
dent can  succeed  in  solving  analytic  problems,  a  physical  processing 
configuration  must  be  defined.  The  physical  processing  configuration 
consists  of  the  logical  and  physical  layout  of  the  data  storage  com- 
ponents. In  other  words,  the  configuration  defines  a  concrete  model 
the  student  must  use  to  solve  assigned  problems.  The  physical  process- 
ing configuration  or  environment  used  in  this  approach  consists  of 
three  physical  components  as  follows:  1)  Input  file  of  records;  2)  glo- 
bal memory  for  program  variables;  and  3)  a  single  output  file.  See 
Diagram  iKS.Ia. 

The  first  component  of  the  configuration,  the  input  file,  is 
sequential.  It  can  contain  records  with  each  record  having  fields  of 
some  elemental  data  type.  The  assumption  is  made  that  all  data  in  the 
file  is  correct  in  terms  of  range  and  ordering.  A  constraint  is  also 
placed  on  the  input  file  that  a  single  record  must   be  read  at  one   time. 
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Input  File  Global   Memory  Output   File 


Diagram  J3.1a  -   Physical    Processing  Configuration 

In  other  words,  the  separate  input  of  individual  fields  in  a  record  is 
not  allowed.  In  addition,  the  constraint  of  having  one  valid  record  and 
a  sentinel   record  is  placed  on  the  input  file. 

The  second  physical  component  of  the  configuration  is  the  global 
memory  for  program  variables.  In  this  component  storage  locations  or 
variables  can  be  created;  and  these  locations  or  variables  can  be  given 
a  value  using  the  below  described  Repetition  Dependent  Primitives  and 
Non^Bepetitlon  Dependent  Primitives.  In  this  component  the  student  is 
able  to  create  memory  locations  of  the  basic  data  types.  The  component 
allows  random  access  to  the  created  locations  during  the  execution  of 
the  coded  module.  Upon  the  creation  of  a  location,  it  is  assumed  to 
contain  a   'garbage  value'. 


The  third  physical  component  is  the  output  file.  This  component  is 
sequential,  and  its  use  is  constrained  to  the  printing  of  a  whole  line 
at  one  time.  In  other  words,  the  printing  of  part  of  a  line  is  not 
allowed  at  the  design  level.  Output  to  this  component  can  include  the 
contents  of  variables  and  program  annotation  from  the  global  memory 
component. 

Page   10 


The  physical  processing  configuration  as  described  above  provides 
the  processing  environment  to  be  used  in  solving  analytic  problems.  The 
reason  for  its  induction  is  that  the  students  are  thus  given  an 
environuent  that  is  constant  from  problem  to  problem  in  which  they  will 
be  asked  to  solve  problems  given  the  procedural  abilities  described 
below   along  with   data  abstraction. 

3.2  Me<;essarY  Abstract  Analytic  Components 

Given  the  above  described  physical  processing  configuration,  the 
abstract  analytic  components  necessary  to  solve  problems  within  that 
configuration  must  be  defined.  These  components  include  both  data 
abstraction  and  the  procedural  primitive  abilities  necessary  to  process 
within  the  configuration  and  Instantiate  the  data  abstractions. 

3.2.1  Data  Abstraction 

The  first   component     necessary     in     analysis     is     the     ability     to 

abstract     the     data  in  the  given  problem.      ACM  defines  data  abstraction 

as 

"The  conceptual  approach  of  combining  a  data  type  with  a  con- 
comitant set  of  operations,  and  the  philosophy  that  such  data 
types  can  be  used  without  knowing  the  details  of  the  underly- 
ing computer   system   representation."   [1] 

However,  this  definition  leaves  out  an  important  concept  in  data 
abstraction.  In  abstracting  data,  the  data  type,  which  is  "a  collection 
of  data  values  and  the  definition  of  one  or  more  operations  on  those 
values.  "[2],  must  not  only  be  dealt  with,  but  the  real  world  meaning  or 
the  semantic  descriptor  must   be  recognized  as  part  of   the  definition  as 
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Hell.  A  semantic  descriptor  can  be  defined  as  the  label  given  to  a 
particular  value  that  must  be  instantiated  (i.e.,  a  value  to  be 
obtained).  This  semantic  descriptor  inherits  a  data  type  and  also 
includes  a  textual  statement  of  the  meaning  within  the  real  world 
environnent.  For  instance  in  the  above  described  Manhattan/McCook  exam- 
ple, arrival  in  the  city  of  Beatrice  is  the  Instantiation  of  a  state  or 
step  in  achieving  the  end  goal  of  reaching  McCook,  and  the  term 
Beatrice  is  the  semantic  descriptor  for  that  desired  state.  In  the  sam- 
ple problem  in  Chapter  Four,  the  term  "call  cost"  is  the  semantic 
descriptor  of  some  real  world  value.  The  call  cost  when  instantiated 
contains  a  value   of  the  inherent  data   type,    real. 

In  solving  the  problems  within  the  defined  problem  domain,  the 
student  must  be  able  to  specify  the  semantic  descriptors  of  the  values 
that  are  contained  in  the  input  file  and  the  semantic  descriptors  of 
all  values  that  need  to  be  derived  to  achieve  the  desired  results  of 
the  analytic  problem.  For  example,  in  the  Manhattan/HcCook  analytic 
problem,  the  student  must  be  able  to  specify  the  cities  or  semantic 
descriptors  that  need  to  be  achieved  or  instantiated  when  driving  the 
route  to  the  final  goal  of  McCook.  In  the  sample  problem  from  Chapter 
Four  the  final  goal  is  to  produce  a  report;  but  to  produce  the  report 
the  'call  cost'  of  each  call  must  be  Instantiated  and  is  but  one  state 
in  achieving  the  final   solution. 

3.2.2   Procedural   Primitive  Abstractions 

With   the  ability   to  specify   the  desired  semantic  descriptors     that 
need     to     be  achieved  or  instantiated  through  data  abstraction  to  solve 
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the  problem,  the  procedural  primitive  abilities  or  abstractions  neces- 
sary to  instantiate  these  values  and  solve  problems  within  the  physical 
configuration  must  be  defined.  Within  the  closure  of  these  primitives, 
all  required  abstract  semantic  descriptors  contained  within  the  defined 
problem  domain  should  be  procedurally  achievable.  Therefore,  the 
remainder  this  chapter  Is  devoted  to  defining  the  allowable  procedural 
primitive  abstractions  to  be  used  in  designing  solutions. 

3.2.2.1    Processing  a  Sentinel  File  Primitive 

The  first  procedural  ability  that  is  necessary  to  solve  problems 
within  the  physical  processing  configuration  is  the  ability  to  process 
the  input  file,  also  known  as  processing  a  sentinel  file.  The  students 
are  given  the  following  design  construct  that  presents  the  logic  of 
inputting  one  record  at  a  time  through   the  sentinel   record: 


READ  FIRST  RECORD 
WHILE  VALID  RECORD 

<primitlves> 


READ  NEXT  RECORD 
ENENHILE 


This  design  construct  is  used  for  every  problem  when  processing  a  sen- 
tinel file  is  required.  An  example  of  the  use  of  this  primitive  is 
found  in  Diagram  #3.2   using  (1)   to  label   the  pieces  of   the   primitive. 

3.2.2.2  Decision  Primitive 

The  second  allowable  procedural    primitive  abstraction  is  the  deci- 
sion    primitive.      This     primitive   provides  the  ability   to   control   which 
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other  allowable  primitives,  if  any,  are  to  be  executed  based  on  a  rela- 
tional test  of  previously  defined  semantic  descriptors  and  program  con- 
stants. This  primitive  provides  two  basic  abilities  for  the  students  in 
relation  to  semantic  descriptors.  The  first  is  the  ability  to  expand 
the  boolean  semantic  information  to  allow  for  Instantiation  of  detailed 
semantic  descriptors.  For  instance,  if  when  necessary  to  instantiate 
the  semantic  descriptor  "in-state  call  count"  from  the  sample  problem 
in  Chapter  Four,  "call"  in  the  semantic  descriptor  can  be  utilized 
through  the  boolean  semantics  of  the  loop  condition;  but  a  test  must  be 
introduced  before  we  can  include  the  words  "In-state"  in  the  semantic 
descriptor.    See  Diagram  #3.2,   (2)    labeling. 

The  second  ability  this  primitive  allows  is  the  variation  in  the 
method  of  instantiation  of  a  semantic  descriptor.  For  instance,  in 
order  to  instantiate  "call  cost"  where  the  method  depends  on  whether 
the  call  cost  is  in-state  or  out-state,  the  decision  primitive  that 
asks  this  question  allows  "call  cost"  to  be  calculated  using  different 
methods.  The  semantics  of  the  value  remain  constant  both  ways,  but  the 
method  of   instantiation  varies. 

^.2.2.^    Becetltion  Dependent  Primitives 

Several  abstract  procedural  abilities  are  based  on  the  repetition 
of  some  value.  In  the  proposed  problem  domain  four  procedural  design 
primitives  are  necessary  to  instantiate  inter-record  semantic  descrip- 
tors during  repetition.  These  primitives  are:  1)  Initialize;  2)  Accu- 
mulate;  3)   Increment;   and     l|)    Select. 
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The  Initialize  primitive  is  used  to  initially  instantiate  the 
semantic  descriptors  of  all  of  the  other  repetition  dependent  primi- 
tives. The  Initialize  primitive  is  used  before  the  use  of  the  Process- 
ing a  Sentinel  File  primitive  to  illustrate  the  procedural  need  to  ini- 
tialize all  of  the  inter-record  based  semantic  descriptors.  The  Ini- 
tialize primitive  is  moved  to  a  high  level  of  abstraction  in  the 
design.  When  designing  the  solution,  all  other  semantic  descriptors  are 
assumed  to  be  initialized  through  the  use  of  a  single  Initialize  primi- 
tive. See  Diagram  *3.2,  (3)  labeling.  In  implementation  of  this  design 
primitive,  the  students  must  find  all  of  the  variables  associated  with 
the  Accumulate,  Increment,  or  Select  primitives  and  instantiate  their 
Initial   state. 

The  Accumulate  primitive  is  necessary  to  derive  the  summation  of 
some  value  that  occurs  multiple  times.  The  Accumulate  primitive  can 
only  be  used  within  the  Processing  a  Sentinel  File  primitive.  The 
Implications  of  the  use  of  this  primitive  in  the  design  are  that  the 
summation  of  some  semantic  descriptor  Is  instantiated.  In  design,  this 
primitive  is  contained  within  a  process  box.  See  Diagram  f3.2,  (1) 
labeling.  In  the  implementation  of  this  design  primitive,  the  syn- 
thetic form  of  X  =  X   +  Y  is  used. 

The  Increment  primitive  is  necessary  because  of  the  need  to  count 
the  number  of  times  some  logical  state  occurs.  The  Increment  primitive 
can  only  be  used  within  the  Processing  a  Sentinel  File  primitive.  The 
implications  of  the  use  of  this  primitive  in  the  design  are  that  the 
number   of   times  the  primitive  is  executed  will   be  derived.      In     design. 
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this  primitive  is  contained  within  a  process  box.   See  See  Diagram  t3.2, 

(5)  labeling.      In  the  Implementation  of   this  design   primitive,    the  syn- 
thetic form  of  X  =  X  +  1    is  used. 

The  Selection  primitive  Is  necessary  because  of  the  need  to  select 
the  largest  or  smallest  instantiation  of  a  semantic  descriptor  based  on 
Inter-reoord  comparison.  The  Select  primitive  can  only  be  used  within 
the  Processing  a  Sentinel  File  primitive.  The  implications  of  this 
primitive  are  that  the  largest  or  smallest  instantiation  of  some 
repetitive  value  is  selected.  In  design,  this  primitive  is  achieved 
through  the  use  of  the  single  sided  decision  primitive  with  Initializa- 
tion of  the  current  state,  testing  of  the  current  state,  and  update  of 
the  current   state  upon  a  true  relational   condition.      See  Diagram     i)3.2, 

(6)  labeling.     In  the  implementation  of  this  design  primitive,    the  fol- 
lowing synthetic  form  is  used: 

IF  <this_reoord_state   [>  <]     current_state>  THEN 

ourrent_'state  < —  thi^record_state 
ENDIF 

3.2.2.1   Non-Hepetitlon  Dependent  Primitives 

The  remaining  abstract  procedural  primitives  are  not  repetition 
dependent.  Therefore  they  can  be  used  anywhere  in  a  solution  design.  In 
the  proposed  defined  problem  domain  five  procedural  design  primitives 
are  necessary  to  instantiate  intra-record  semantic  descriptors  or 
semantic  descriptors  that  can  be  instantiated  without  repetition.    These 
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primitives     are:      1)   Read;   2)   Print;   3)   Calculate;   1|)    Set;   and  5)    Build 
and  Extract. 

The  Head  primitive  is  necessary  to  transfer  one  complete  record 
from  the  input  file  component  to  the  semantic  descriptors  in  the  global 
memory  component  of  the  physical  processing  configuration.  The  implica- 
tions of  this  primitive  are  that  a  complete  record  is  transferred  to 
the  global  memory  component  to  the  respective  semantic  storage  loca- 
tions for  later  use,  and  the  intrinsic  pointer  in  the  input  file  is 
advanced  to  the  next  record.  In  design,  this  primitive  is  included 
within  an  I/O  flowchart  box.  See  Diagram  if3.2,  (7)  labeling.  In 
implementation  of  this  design  primitive,  the  synthetic  form  of  READ 
<variable  list>  is  used. 

The  Print  primitive  is  necessary  to  transfer  information  from  the 
global  memory  component  to  the  output  file  component.  The  implications 
of  this  primitive  are  that  at  least  one  line  of  formatted  output  is 
produced,  and  the  intrinsic  pointer  in  the  output  file  is  advanced  to 
the  next  empty  line.  In  design,  this  primitive  is  included  in  an  I/O 
flowchart  box.  See  Diagram  iJ3.2,  (8)  labeling.  In  implementation  of 
this  design  primitive,  the  synthetic  form  of  PRINT  <varlables  and  anno- 
tatlon>  <formatting>  based  on  the  respective  implementation  language  is 
used. 

The  Calculate  primitive  is  necessary  to  mathematically  instantiate 
a  semantic  descriptor  within  the  global  memory  component  when  the  pro- 
cedural ability  to  Instantiate  the  semantic  value  does  not  require 
repetition.      The     implications     of     this     design     primitive     are   that  a 
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semantic  descriptor  has  been  instantiated  through  some  arithmetic 
operatlon(s).  In  design,  this  primitive  is  included  In  a  flowchart  pro- 
cess box.  See  Diagram  t3.2,  (9)  labeling.  In  the  implementation  of 
this  design  primitive,  the  synthetic  form  of  X  =  <arithmetio  expres- 
sion>  is  used. 

The  Set  primitive  is  necessary  to  Instantiate  the  state  of  some 
semantic  descriptor  without  the  use  of  arithmetic  or  string  operations. 
The  implications  of  this  design  primitive  are  that  the  state  of  some 
semantic  descriptor  is  instantiated.  In  design,  this  primitive  is 
included  in  a  flowchart  process  box.  See  Diagram  #3.2,  (10)  labeling. 
In  the  implementation  of  this  design  primitive,  the  synthetic  form  of  S 
or  X  =  <constant>  is  used. 

The  Build  and  Extract  design  primitives  are  necessary  to  perform 
operations  on  character  strings.  The  selection  of  the  verb  is  based  on 
the  semantics  of  the  operation.  The  implications  of  the  use  of  these 
primitives  are  that  a  string  semantic  descriptor  has  been  instantiated 
through  operations  on  other  string  values.  In  design,  these  primitives 
are  included  in  a  flowchart  process  box.  See  Diagram  S3. 2,  (11)  label- 
ing. In  the  implementation  of  these  design  primitives,  the  synthetic 
form   of  S  =   <string  expression>  is  used. 

3.3  Conclusion 

This  chapter  presents  the  defined  problem  domain  in  which  the  stu- 
dent will  be  asked  to  solve  problems.  By  creating  the  defined  problem 
domain  for   the  students,    they  are  no  longer   asked  to     design     solutions 
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to  problems  at  the  language  abstraction  level.  Instead  they  are  able  to 
use  a  concrete  computer  model  to  represent  the  computer  system  or  phy- 
sical environment  and  are  then  able  to  design  the  solution  to  the 
assigned  problems  using  the  allowable  procedural  primitives  at  a  level 
of  abstraction  closer  to  English  sentence  representation  used  in  other 
disciplines. 
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Diagram   #3.23  -    Procedural    Primitives 
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CHAPTEH  H 
ANALmC  PaOBLEM  SOLVING    PROCESS 


In  the  proposed  course  design  for  CS1  once  tbe  students  understand 
the  defined  problec  domain  they  will  be  asked  to  solve  formal  analytic 
problems  within  the  domain.  As  explained  in  Chapter  Two,  the  goal  in 
any  analytic  problem  is  to  completely  specify  the  problem  (i.e.,  to 
completely  specify  the  preconditions,  the  postconditions,  and  the 
actions  to  perform  the  translation).  The  students  in  CS1,  as  part  of 
the  analytic  problem  solving  process  as  presented  in  the  course,  must 
specify  the  preconditions  and  postconditions  of  the  problem  as  given  in 
terms  of  the  physical  processing  configuration.  Next  they  must  design  a 
solution  to  the  problem.  Lastly,  the  students  must  Implement  tbe  design 
into  a  high  level  language.  The  course  provides  the  following  six 
phases  which  are  designed  to  lead  the  students  through  these  steps  to  a 
complete  specification  of  a  formal   analytic  computer  science  problem: 

1)  Specification  of   Pre-   and  Postcondition  Phase; 

2)  Design  Phase; 

3)  Pre-coding  Phase; 
1)   Coding  Phase; 

5)  Testing  Phase;   and 

6)  Documentation  Phase. 

For  each  of  the  above-listed  phases  of  the  problem  solving  pro- 
cess, the  inputs  to  the  phase,  the  desired  results  frooi  the  phase,  and 
the  necessary  translation  algorithms  to  be  used  to  derive  this  desired 
result  from  the  Inputs  are  defined.  Thus  this  model  of  the  problem 
solving  process,  in  essence,  presents  a  synthetic  model  for  the  stu- 
dents to  solve  formal  analytic  problems  within  the  defined  problem 
domain.  ;  - 
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The  above  listed  six  phases  are  explained  in  this  chapter.  In 
order  to  dearly  illustrate  these  six  components  of  the  model,  a  sample 
problem,  which  is  described  below,  is  used.  This  problem  is  selected 
because  it  utilizes  all  of  the  primitive  procedural  and  data  abstrac- 
tion abilities  that  are  within  the  defined  problem  domain  as  presented 
in  Chapter  Three. 

SAMPLE  PROBLEM: 

CS  20x  LAB 
PHONE  COMPANY 

Given  an  input  file  that  contains  the  information 
for   one   customer   to  the  MUW   phone  company.    The  file 
contains  a  header  record  with    : 

1.  the  customer   area  code         '913' 

2.  customer   number  '11567  892' 

3.  monthly   service   charge         16.75 

The  remainder  of  the  records  are  the  phone  calls  that 
were  made  during  the  month  by  the  above  customer  and 
includes  the  following  information  for  each   : 

1.  Area  code  called  '913' 

2.  Number  called  '5638976' 

3.  Time  of   the  call  '1020'  for   10:20 
1(.  seconds  of  the  call  310 

Create  a  bill   to  the  customer   that   prints  on  the  top 

appropriate  headings  with   the  customer   phone   number 

inserting  dashes  and  parentheses  in  the  out   area  form 

stated  below. 
For   each  call   record,    print   on  the  detail   line   an  '0' 

If   the  call  was  out   of   the  customer   area  code  else 

a  blank.    Then  print   the  number   called  in  following 

forms,    the  minutes  of   the  call,    the  time  of   the  call, 

and  the  charge  based  on  the  following  table. 

PHONE  FORMS     in  area     :   563-8976 

out  area   :    (112)   563-8976 

BILLING    RATES 

In  area       $.20   per  minute 
Out  area     $.21   per  minute 
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Totals  to  be  kept  are   : 

1.  Count  In-area  calls,    out-area  calls,    and  all   calls. 

2.  In  area  call   cost,    out  area  call   cost 

and  total   call   cost. 

3.  State  tax  at  3?   of   all   calls. 

1.   Federal   tax  at  H%  of   all   out-area  calls. 

5.  The  amount  to  be   paid  by   the  customer. 

6.  The  number   and  amount   of   the  most  expensive  call. 


1.1   Scecification  of  Pre-   and  Postcondition  Phase 

In  analytic  problems  the  preconditions  (input  description)  and  the 
desired  result  (output  description)  are  given,  and  the  student  is  asked 
to  generate  the  actions  to  make  the  translation.  In  the  specification 
phase  of  the  model,  the  goal  is  to  formally  define  both  the  precondi- 
tions and  the  postconditions  of  a  given  textual  problem  such  as  the 
above  described  sample  problem  in  terms  of  the  physical  processing  con- 
figuration. This  specification  is  aooomplished  in  preparation  for  the 
designing  of  the  translation  or  the  solution  to  the  analytic  problem 
within  the  defined  problem  domain. 

The  terns  precondition  and  postcondition  can  be     defined     as     fol- 

loNs: 

Precondition 

"A     condition     that     must     be     true     before     the     current 
lnatruction(3)   will  do  what  we  want," 

Postcondition 

"The  result  of  executing  an  lnstruction(s)"[2] 

"The  pre-  and  postconditions  are  really  the  values  of  all  the  variables 
we  have  used  at  any  point  in  the  algorithm  and  the  current  state  of  the 
data  list  and  output  list.  "[2] 
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The  specification  phase  of  the  model  follows  these  basic  defini- 
tions. In  specifying  the  problem  the  students  are  asked  to  define  the 
state  of  all  three  components  of  the  physical  processing  configuration 
before  and  after  the  activation  of  the  global  module  as  a  whole.  The 
state  of  the  components  during  the  activation  of  the  module  is  not  of 
concern.  Instead,  the  students  must  specify  the  state  of  the  input 
file,  global  memory,  and  output  file  components  before  the  execution  of 
the  module  (preconditions).  The  students  must  also  specify  the  desired 
state  of  these  components  after  the  module  has  been  executed  (postcon- 
ditions). This  specification  of  the  state  of  the  three  components  of 
the  physical  processing  configuration  are  further  explained  below 
through  the  use  of  the  sample  problem. 

It.  1.1   Specification  of  Incut  File  Component 

— Precondition  of   the  Input   File 

In  solving  the  sample  problem  the  students  must  specify  the 
precondition  or  state  of  the  input  file  before  the  execution  of  the  set 
of  code  (or  soon  to  be  derived  actions).  A  modeling  component  is  needed 
because  the  form  of  the  input  file  will  vary  from  problem  to  problem. 
Diagram  f1.1a  Illustrates  the  proposed  modeling  component  as  applied  to 
the  sample  problem. 

This  graphical  view  represents  a  file  which  is  broken  into  records 
and  fields.  Each  field  is  labeled  with  a  semantic  descriptor  and  the 
type  of  information.  The  last  row  or  record  Is  dedicated  to  the 
description     of     the     sentinel     record.        If   the  instructor  feels  it  is 
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Diagram  Jl.la  -   Precondition  of   Input  File 
necessary,    the  range   of   the  field  can  be  defined. 

To  derive  this  component  the  students  are  required  to  to  analyze 
the  given  textual  problem,  extract  the  respective  input  requirements, 
and  completely  specify  these  requirements  in  a  defined  formal  model. 
The  model  allows  for  the  complete  abstract  specification  of  the  con- 
tents of  the  file  in  terms  of  records,  fields,  and  the  termination  con- 
dition. 


The  selection  of  a  value  is  made  in  one  of  the  fields  of  the  last 
record  to  represent  the  sentinel  value.  In  this  case  the  word  'TRASH' 
will  be  placed  in  the  RECEIVER  AREA  CODE  field.  The  selection  cf  the 
sentinel  value  can  either  be  given  by  the  Instructor  or  defined  by  the 
student,    depending  on  the  management   of   the  data   set. 

— Postcondition  of   the  Input  File 

Next  the  students  must  specify  the  state  of  the  input  file  after 
the  execution  of   the  global   module  of   code.    In  the  environment  for   this 
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course  as  explained  In  Chapter  Three,  one  record  at  a  time  must  be  read 
from  the  input  file  through  the  sentinel  record.  The  state  of  the  file 
after  the  execution  of  the  module  within  the  scope  of  the  elemental 
problems  presented  in  the  course  will  be  trivial.  Simply  stated,  all 
records  will  have  been  read.  The  students  should  derive  the  following 
postcondition  for   the  input  file  component: 


Postcondition  of   the  Input  File 

The  file  will   be  read  through   the  sentinel   record. 


1.1 .2   Epeoifleatlon  of  Global  Memory  for  Program  Variables  Component 

The  pre-  and  postcondition  of  the  global  memory  component  for  a 
global  module  is  based  on  the  abstract  view  that  the  binding  of  the 
variables  to  memory  locations  and  the  ability  to  reference  these  vari- 
ables only  exists  during  the  activation  of  the  global  module.  Reference 
to  these  variables  exists  only  upon  activation  of  the  module  in  a  com- 
piled environment  and  upon  use  in  an  interpreted  environment  such  as 
BASIC.  These  variables  become  dereferenced  upon  completion  of  the  glo- 
bal module. 

—  Precondition  of  Global   Memory   Component 

From  the  above  abstract  view  it  can  be  understood  that  no  vari- 
ables exist  before  the  activation  of  the  module.  Thus  in  a  £dobal 
module  program,  the  precondition  of  the  global  memory  component  is  as 
follows: 
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Precondition  of  Global   Memory   Component 
No  variables  can  be  referenced 


— Postcondition  of  Global   Memory   Component 

After  the  execution  of  the  module  the  variables  are  dereferenced 
and  not  accessible  in  compiled  environments.  However,  In  an  Interpreted 
environment  the  variables  exist  until  they  are  cleared  by  a  system  com- 
mand such  as  editing  the  program.  The  assumption  is  made  that  no 
reference  to  the  variables  exists  in  the  global  memory  component  after 
the  execution  of  the  global   module. 

In  actuality  both  the  pre-  and  postcondition  of  this  component  for 
any  problem  will  remain  constant  from  problem  to  problem  and  therefore 
need  not  be  specified.  For  completeness,  however,  the  following  textual 
statement  can  be  Included  in  the  specification: 


Preconditions  of  the  global  memory  component 
No  variables  can  be  referenced 

Postconditions  of   the  Internal   memory 
Ho  variables  can  be  referenced 


1.1.3   EDecifloatlon  ^  J^hg  Output  File  Component 

The  third  task  that  the  students  must  perform  in  the  specification 
phase  is  to  define  the  pre-  and  postcondition  of  the  output  file  com- 
ponent. The  major  goal  in  any  problem  is  to  input  data,  process  it,  and 
output  results.  The  specification  of  the  pre-  and  postconditions  of  the 
output  file  will   represent  the  desired  effect  that  the  module  will   have 
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on  tbe  output  file  component. 

— Precondition  of   the  Output  File  Component 

The  problems  for  this  course  are  designed  to  produce  results  to  an 
output  file.  The  existence  of  an  output  file  is  the  necessary  precondi- 
tion throughout  all  of  the  problems  that  the  students  will  solve. 
Therefore,  the  major  precondition  of  the  global  module  output  file  in 
anjr  problem  is  as  follows: 


Precondition  of  Output  File 
An  output  file  exists 


—  Postcondition  of   the  Output  File  Component 

The  state  of  the  output  file  after  the  execution  of  the  global 
module  is  the  desired  result  of  the  synthesis  of  the  data  values 
through  the  soon  to  be  designed  and  coded  instructions.  This  state 
varies  from  analytic  problem  to  analytic  problem.  Therefore,  the  stu- 
dents must  specify  a  prototype  of  the  output  file  component  to  model 
the  desired  state  of  this  component  after  the  execution  of  the  global 
module.  The  students  should  derive  the  prototype  in  Diagram  Jll.lb  as 
the  postcondition  of   the  output  file  component  for   the  sample  problem. 

Problems  that  are  given  to  the  students  are  normally  given  in  tex- 
tual sentence  based  English.  In  the  creation  of  a  prototype  such  as 
illustrated  above,  the  students  must  analyze  the  assigned  problem  and 
extract     the  requested  output  values.      These  requested  values  iDust   then 
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CDSTOMEH  NUMBER    :    %  %     DATE    :    %  t 

ITEKIZED  BILL 

NUMBER    CALLED  TIME     MINUTES  COST 


i%  %  %         %       t       ttU  Utt.U 


raUR  MOST  EXPENSIVE  CALL   HAS   TO  J 
AND  COST  Utt.ilt 


NUMBER   OF 
CALLS 

COST 

m    AREA 
ODT  AREA 

Hit 

tttt.tt 
tttt.tt 

SUMMARY            ant 

STATE   TAX 
FEDERAL   TAX 
SERVICE   CHARGE 

f  tttt.tt 

tttt.tt 

tttt.tt 

itt.tt 

PAY  THIS    AMOUNT  ttttt.tt 

Diagram  *1.1b  -  Postcondition  of   the  Output  File 

be   organized  Into  a  machine   creatable     format     with     proper     annotation 
specifying  the  semantic  descriptors  of   the  output  values. 

The  generation  of   this  prototype  has  a  two-fold  effect.      First,    it 

forces     the  students  to  restate   the  desired  result,    and  second,    it  also 

presents  an  exact  replica   of   the  output  to  be     generated     for     use     in 

design  and  implementation  by   the  students.  The  prototype  generated  for 
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any   problem  presents  the  logical   order   of  processing.    For  example,      the 

goal     In     the  sample   problem  Is  to  create  this  report  and  by   the  nature 

of   the  output  mechanism  must  be  done  from  the  top  of   the  prototype     to 
the  bottom. 

In  any  prototype  pound  signs  are  used  to  Illustrate  variable 
numeric  fields,  and  percent  signs  are  used  to  represent  the  boundary  on 
variable  character  fields.  A  reference  line  is  induced  to  map  the 
columns  in  the  component.  The  necessary  annotation  is  also  Included  and 
should  be  the  exact  annotation  that  is  produced  in  the  implementation 
of  the  solution. 

1.1. t   Conelusion  ts  Specification  Phase 

In  summary,  the  goal  of  the  specification  of  the  pre-  and  postcon- 
dition phase  is  to  specify  the  pre-  and  postconditions  of  the  formal 
analytic  problem  within  the  context  of  the  physical  processing  confi- 
guration. The  specification  of  the  pre-  and  postconditions  represent 
the  given  parts  of  a  formal  analytic  problem.  In  actuality,  as  shown 
above,  only  the  precondition  of  the  input  file  component  and  the 
postcondition  of  the  output  file  component  vary  from  problem  to  prob- 
lem; all  of  the  other  pre-  and  postconditions  remain  constant.  However, 
for  completeness  and  to  allow  the  students  to  better  understand  the 
extension  of  the  model  to  the  specification  of  submodules  later  in  the 
CS1  course,  the  students  are  asked  to  specify  all  pre-  and  postcondi- 
tions for  each  analytic  problem  to  be  solved.  A  complete  specification 
of  the  sample  problem  would  look  like  Diagram  *i).1c  and  Diagram  Jl.ld. 
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INPUT  FILE   : 
Precondition 


I  Customer 

I  area  oode 

I  char 

I  length  3 


I   Receiver 
I   area  code 


I       char 
I     length  3 


•TRASH' 


Customer 
number 


char 
length  7 


Service 
charge 


real 


header  record 


-I. 


Receiver      |   Time          |   Seconds! 
number          I   of   call    |   of   oall|   transaction 
I I I     records 


char        I   char  1 
length  7   1 


Int 


Postcondition   : 

1.    the  file  will   be  read  through   the  sentinel   record 

INTERNAL   VARIABLES 
Precondition     : 

1.  No  internal  variables  can  be  referenced 
Postcondition  : 

2.  No  internal   variables  can  be  referenced 


Diagram  Jt.lc  -     Specification  of   Sample  problem 
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OOTPDT  FILE 
Precondition     : 

1.   Output  file  must  exist 

Postcondition  : 

123 ')5678901231567890123«56789012315678901 231567890 

ICH    PHONE  COMPANY 

CDSTCMER  mmSR    :    %  %     DATE    :    %  % 

ITEMIZED  BILL 
NOHBES   CALLED  TIME     MINUTES  COST 


YOOH  MOST  EXPENSIVE  CALL  HAS   TO  J 
AND  COST  tttt.tt 


NUMBER    OF 
CALLS 

COST 

IN    AREA 
00 T  AREA 

tttt 
tttt 

tttt.tt 
tttt.tt 

SUMMARY            tttt 

STATE   TAX 
FEDERAL    TAX 
SERVICE   CHARGE 

ttttt.tt 

tttt.  tt 
tttt.tt 

ttt.tt 

PAY  THIS 

AMOUNT 

ttttt.tt 

Diagram  l.ld  -  Specification  of  Sample  Problem  (cont) 

The  remaining  five  phases  to  be  completed  by  the  students  involve 
the  specification  of  the  third  part  of  any  formal  analytic 
problemCi.  e. ,    the  specifying  of   the  actions  to  perform   the     translation 
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from     precondition     to     postcondition).      The     remainder   of  this  chapter 
explains  those  five  phases. 

H.2  Design  Phase 

In  the  first  phase  of  the  problem  solving  process  called  the 
specification  phase,  the  students  must  formally  define  the  pre-  and 
postconditions  of  the  given  analytic  problem  within  the  context  of  the 
physical  processing  configuration.  In  the  second  phase  called  the 
design  phase  the  goal  is  for  the  students  to  define  the  translation 
from  the  preconditions  to  the  postconditions  using  the  allowable  pro- 
cedural design  primitives  within  the  defined  problem  domain.  In  the 
design  phase  the  students  accomplish  this  translation  through  the  use 
of  semantic  descriptors  and  the  allowable  procedural  primitives.  The 
task  of  the  students  is  to  abstract  and  define  the  semantic  descriptors 
of  the  values  in  the  problem  and  place  these  semantic  descriptors  with 
the  procedural  primitive  that  instantiates  each  descriptor  using  their 
cwn  thought  processes  and  the  instructor  as  verification  tools.  See 
Diagram  tH.2z  and  tH.2b.  Essentially  upon  completion  of  the  design 
phase,  the  students  have  mapped  out  the  basic  solution  to  the  analytic 
problem. 

Students  in  CS1  generally  find  the  development  of  the  basic  steps 
for  solving  an  analytic  problem  to  be  the  most  difficult  part  of  the 
course.  The  design  phase  forces  the  student  to  specify  these  steps  out- 
side the  environment  of  the  computer  Itself  in  an  abstract  form  before 
attempting  to  implement  the  abstraction  using  a  high-level  language. 
For     instance,      since     certain     semantic     descriptors     are  Instantiated 
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through  accumulation,  the  students  must  specify  this  process  within  a 
repetition  primitive  In  a  form  that  represents  the  proper  procedural 
method  of  instantiation.  The  students  simply  state  "Accumulate"  along 
with   the  associated  semantic  descriptor. 

This  approach  to  design  does  not  use  top-down  design  strategies. 
The  course  approaches  the  design  by  attacking  the  whole  problem  at  one 
level  of  abstraction.  The  student  must  learn  to  design  a  global  module 
before  decomposition  or  top-down  strategies  can  be  applied. 

In  designing  the  solution  to  the  problem  in  the  design  phase,  the 
students  have  available  two  possible  forms  as  follows:  1)  Linear  Tex- 
tual form;  and  2)  Graphical  Flowchart  form.  The  two  possible  design 
forms  of  the  sample  problem  are  illustrated  below  in  Diagram  fH.2z  and 
Diagram  #1.2b.  The  explanation  and  analysis  of  reasoning  for  the  design 
is  left  to  the  reader.  There  is  no  logical  difference  between  which 
method  is  used;  however,  this  author  strongly  recommends  the  use  of  the 
graphical  flowchart  form  for  teaching  introductory  students  because  of 
its  graphical   nature  in  nesting  decision  structures. 

Dpon  careful  analysis  of  the  two  possible  forms,  differences  can 
be  found  in  the  level  of  abstraction  that  was  used  in  the  design  of  the 
solution  to  the  sample  problem.  The  design  phase  has  no  electronic 
validation  method.  The  level  of  abstraction  that  is  used  is  totally  up 
to  the  instructor  teaching  the  course.  For  instance,  in  the  graphical 
flowchart  form  the  step  of  printing  the  headings  on  the  top  of  the 
report  using  a  single  I/O  box  is  defined.  This  defers  the  analysis  and 
abstraction     of  printing  all   of   the  lines  in  the  headings  to  the  coding 
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phase.  This  deference  can  be  construed  as  a  first  step  in  top-down 
design.  In  the  linear  textual  form,  the  printing  of  each  line  in  the 
headings  is  specified  and,  therefore,  is  designed  at  a  lower  level  of 
abstraction. 


Diagram  JH.Sa  -   Linear  Textual   Form  of  Design 

BECIN    ALGORITHM 

INHIALIZE  ACCUMDLATOHS  AND  SaECTOHS 

READ  HEADER   RECORD 

BUILD  CUSTOMER   PHONE  FOR  DISPLAY 

PRINT  TOP  HEADING 

PRINT  LINE 

PRINT  CUSTOMER   DETAIL   LHE 

PRINT  LINE 

PRINT  REPORT  TOP  HEADING 

PRINT  COLUm   HEADING 

PRINT  LINE 

INITIALIZE  CALL  LOOP  BI  HEADING    CALL    RECORD 

WHILE  NOT  SENTINEL    RECORD 

CALCULATE  MINUTES   OF  CALL 

IF  CALL    IS   IN    AREA  THEN 

SET  AREA  DISPLAY  TO  BLANK 
CALCULATE   CALL   COST 
BUILD  CALL   NUMBER   FOR   DISPLAY 
INCREMENT   IN    AREA  COUNT 
ACCUMULATE   IN   CALL   COST 
ELSE 

SET  AREA  DISPLAY  TO    '0' 
CALCULATE  CALL   COST 
BUILD  CALL   NUMBER   FOR   DISPLAY 
INCRE^ENT  GOT  AREA  COUNT 
ACCUMULATE  OUT  AREA  CALL   COST 
ENDIF 

BUILD  TIME   OF  CALL   FOR  DISPLAY 
PRINT  DETAIL   LME 

IF  COST  OF  THIS   CALL   IS  GREATER    IHAIJ   LARGEST  THEN 
SET  LARGEST  CALL   COST  TO   IBIS   COST 
SET  LARGEST  CALL   NUMBER    TO    IHIS   NUMBER 
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EHDIF 

UPDATE  CALL  LOOP  BY  READING    NEXT  RECORD 
ENDHHILE 

PRINT  LINE 

PRINT  LARGEST  COST  LIKES 
PRINT  SUMMARY  HEADINGS 
PRINT  LINE 

PRINT  U)    AREA  SUMMARY 
PRINT  ODT  AREA  SUMMARY 
PRINT  LINE 

CALCULATE  TOTAL   CALL   COUNT 
CALCULATE  TOTAL    CALL   COST 
PRINT  TOTAL   CALL    SOMMARY 
CALCULATE  STATE  TAX 
CALCULATE  FEDERAL   TAX 
CALCULATE  AffiUNT  TO  BE   PAID 
PRINT  STATE   TAX  LINE 
PRINT  FEDERAL   TAX  LINE 
PRINT  SERVICE   CHARGE  LINE 
PRINT  LIME 

PRINT  AMOUNT  TO  BE  PAID  LINE. 
END  ALGORITHM 
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Ciagran   i"1.2b   -  Graphical    Flowchart  For 
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In  the  design  phase  of  the  problem  solving  process  the  students 
must  specify  which  steps  must  occur  to  solve  the  analytic  problem.  In 
the  design  phase  the  implementation  of  each  primitive  has  not  been 
specified,    but   only   that  they  need  to  occur. 

The  students  must  understand  that  the  design  for  a  given  problem 
cannot  be  executed  by  the  computer  but  must  be  translated  into  a  formal 
computer  language.  The  correctness  of  the  design  cannot  be  guaranteed 
by  any  system  checker.  The  correctness  can  only  be  measured  by  visual 
inspection  and  analysis.  If  the  semantic  descriptors  and  the  primi- 
tives meet  the  actual  needs  of  the  problem,  then  a  correct  design  has 
been  developed.  It  is  very  important  to  have  a  visual  inspection  by  an 
outside  source  to  check  the  design  by  the  students.  If  the  design  is 
incorrect,  then  the  frustrations  are  later  multiplied.  The  students 
should  be  able  to  specify  on  the  abstract  level  what  is  to  be  done 
before  the  actual   implementation  is  to  begin. 

after  careful  inspection  of  the  design,  implementation  of  the 
design  can  begin.  During  the  implementation,  problems  with  the  design 
will  surface.  The  inadequacies  that  are  found  in  the  design  during 
implementation  should  be  reflected  backward  in  the  model  in  the  design 
phase.  The  design  component  needs  to  be  updated  as  these  problems 
arise.  When  the  student  submits  the  final  solution,  all  components 
should  be  cohesive. 
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1| . 3   Pre-Coding  Phase 


The  third  phase  of  the  problem  solving  process  is  called  the  pre- 
ceding phase.  During  this  phase  the  students  must  predefine  all  user- 
defined  identifiers  which  form  the  data  dictionary  to  be  used  in  cod- 
ing. The  generation  of  these  user-defined  identifiers,  specifically, 
the  module  name,  the  input  variables,  the  process  variables,  and  the 
format  variables,  have  direct  synthetic  algorithms  from  the  specifica- 
tion and  design  components  which  are  input  to  this  phase.  When  the  stu- 
dents develop  these  user-defined  identifiers,  they  must  generate  a 
variable  name  or  format  list  and  also  determine  the  proper  placement  of 
reference  to  each  variable  within  the  specification  and  design  com- 
ponents. In  this  third  phase  of  the  problem  solving  process,  the  stu- 
dents must  for  the  first  time  apply  the  language  dependency  rules.  The 
generation  of  the  identifiers  and  format  lists  must  adhere  to  the 
language  syntax.  The  variable  names  that  are  created  during  this  phase 
are  the  only  ones  that  are  to  be  used  during  the  coding  of  the  solu- 
tion. A  complete  specification  of  the  variables  and  formats  to  be  used 
and  their  logical  positioning  in  the  specification  and  design  com- 
ponents allows  for   direct  translation  Ir  the  coding  phase. 

1.3.1   Module  Name 

The  first  user-defined  identifier  in  the  pre-coding  phase  is  the 
module  name.  Once  defined,  this  identifier  becomes  the  r.ame  of  the  pro- 
gram in  the  coding  phase.  In  top  down  design  this  name  is  derived  fran 
the  semantic  call  to  this  routine.  But  in  the  proposed  course  design  a 
name  for   the  global   module  is  derived  by   just   creating     an     appropriate 
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name.      The  name  of   our   sample   program  will   be   PHONE_BILL. 

1.3.2   Incut  Variables 

The  second  step  of  the  pre-oodlng  phase  is  the  generation  of  the 
Input  variables  from  the  precondition  component  of  the  input  file.  For 
every  field  in  this  component,  a  variable  of  the  respective  data  type 
must  be  generated.  Diagram  iJll.Sa  illustrates  the  derivation  of  the 
input  variables  in  the  pre-coding  phase  of   the  sample  problem. 


Customer 
area  code 


char 
length  3 


Receiver 
area  code 


char 
length  3 


•TBASH' 


I. 


Customer 
number 


Service    | 
charge    I   customer 
I   record 


char 
length  7 


Receiver 
number 


real 


Time 
of  call 


I   Seconds  I 


char       I  char  4 
length  7   I 


of  call  I     call 
I     records 


Int 


Input  Variables 
COS_AREA_CODE$ 
COS_HUMBER$ 
SERVICE.  CHARGE 
REC_AREA_CODE$ 
REC_NUMBER$ 
TIMELOF_CALL$ 
SECONDS_CF_CALL 


CHAR  3 
CHAR  7 
REAL 
CHAR  3 
CHAR  7 
CHAR  1| 
IN  TEG  EH 


Diagram  t.3a  -  Derivation  of   Input  Variables 

The  generation  of  these  variables  can  be  written  directly  into  the 
program  file  as  documentation  or  declarations  or  can  be  written 
separately.      When  the  graphical   flowchart  form   is  used,      the     variables 
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should  be  written  beside  the  respective  input  box  that  specifies  the 
record  being  read  for  later  reference.  See  Diagram  #1.2.  When  the 
linear  textual  form  is  used,  the  variables  should  be  placed  fcesSb.  When 
the  linear  textual  form  is  used,  the  variables  should  be  placed  beside 
the  respective  textual   statement   that  inputs  the  record. 

I1.3.3   Process  Variables 

The  third  category  of  variables  to  be  generated  are  the  process 
variables.  One  variable  is  generated  for  every  unique  semantic  descrip- 
tor contained  within  a  process  box  which  begins  with  the  calculate, 
accumulate,  Increment,  set,  build,  or  extract  statements  frcm  the 
design  phase.  For  example  in  Diagram  #11. 3b,  a  process  box  exists  which 
instantiates  the  IN_AREA_COONT,  and  also  a  process  box  exists  that 
instantiates  the  OUTLAREiL COUNT.  The  semantic  descriptors  in  these 
process  boxes  are  different  and  therefore  warrant  the  creation  of  a 
separate  variable  for  each  process  box.  A  single  variable  is  created 
for  multiple  process  boxes  when  the  semantic  descriptors  are  the  same. 
For  instance  in  Diagram  #l|.3b,  one  variable  is  created  called  CALt^COST 
for  two  separate  process  boxes.  This  is  done  because  the  semantic 
descriptor  in  both  oases  is  CAU^COST.  In  this  case,  only  the  method  of 
instantiation  varies,  not  the  semantic  descriptor  of  the  value.  Thus 
one  variable  is  used  for   both  process  boxes. 

When  the  graphical  flowchart  form  is  used  the  variables  should, 
for  coding  reference  purposes,  be  written  beside  the  respective  boxes 
in  the  design.  The  variable  should  simply  take  the  form  of  the  semantic 
descriptor     in     the  box.    If  linear   textual   form  is  used,    the  respective 
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variables  should  be  placed  beside  or  below  the  primitive  that  instan- 
tiates this  semantic  value.  Below  is  the  generation  of  the  input  and 
process  variables  using  the  graphical  flowchart  form  which  was  input  to 
this  phase. 
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Diagram   i!il|.3b 
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11.3.1   Format  Variables 

The  next  step  in  the  pre-ooding  phase  Is  to  develop  the  formats 
that  are  necessary  to  format  output  information.  This  method  varies 
depending  on  the  language  to  be  used  in  implementation.  If  the 
language  uses  a  graphical  representation,  like  BASIC,  the  output  pic- 
ture itself  specifies  the  formats.  A  variable  needs  to  be  created  for 
every  line  in  the  output  file  postcondition  model  to  hold  the  represen- 
tation of  the  format  in  the  coding.  The  specification  of  the  format 
variables  should  be  placed  beside  the  respective  line  in  the  output 
postcondition  that  it  will  format.  Also  the  variable  name  can  be  placed 
on  the  design  component  for  use  in  the  coding  phase.  These  two  refer- 
ence  patterns  are  shown  in  Diagram  m.Sc  and  Diagram  *t.3d. 
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Diagram  ;i.3c  -  Format  Reference   Placement 


Page  15 


Diagram  tl.Zi  -  Flowchart  With   All   Necessary  Variables 
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In  a  language  such  as  FORTRAN,  formats  are  numbered,  and  a  numeric 
list  representation  is  generated.  The  numbers  need  to  be  posted  on  the 
input  specification  and  the  respective  format  lists  generated.  These 
numbers  then  need  to  be  placed  in  the  design  component  by  the  respec- 
tive print  primitive  that  will  use  this  format.  Diagram  #l|.3e  illus- 
trates the  necessary  reference  and  format  list  generation  for  the 
language  FOHTRAH. 
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SERVICE  CHARGE  tU.H  1090 
,065 

PAY  THIS   AMOONT  itttt.ff  1100 

1000     FORMAT   (16X,    'MJW    PHONE  COMPANY") 

1005     FORMAT    (19(  '-')) 

1010     FORMAT    ('COSTOMER  NUMBER    :    ',    All,   2X,    'DATE    :    ',    A8) 

Diagram  *1.3e  -  FORTRAN   Format  Reference 
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other  methods  need  to  be  developed  for  implementation  using  other 
languages.  The  development  of  the  formats  Is  an  analysis  of  the  output 
file  postcondition  model.  Writing  of  the  above-listed  structure  for- 
mats before  coding  begins  can  be  moved  to  a  dynamic  generation  of  for- 
mats during  coding  when  the  students  become  competent  in  format  genera- 
tion. The  rewriting  of  the  formats  becomes  unnecessary  once  the  skill 
is  developed.  But  the  necessity  of  specifying  the  variable  or  number  of 
each  format  within  the  design  and  output  file  postcondition  model  does 
not  change. 

it.H   Coding  Phase 

The  solution  to  the  formal  analytic  problem  is  developed  by  the 
students  in  the  design  phase  in  an  abstract  form,  and  in  the  pre-coding 
phase  the  user  defined  identifiers  of  the  coding  phase  are  specified. 
The  next  step  in  this  synthetic  model  for  solving  analytic  problems 
requires  the  students  to  code  the  designed  solution  into  the  syntax  of 
a  high-level  language.  The  word  "coding"  in  this  report  will  refer  to 
the  translation  by  hand,  using  pencil  or  pen,  of  the  design  into 
language  instructions.  Given  correct  inputs  to  this  phase,  the  coding 
becomes  a  synthetic  process. 

In  the  coding  of  the  program  the  language  program  structure  and 
the  design  phase  component  must  be  followed  directly.  For  the  students 
to  succeed  in  the  translation  of  the  design  into  code,  access  to  sample 
programs  needs  to  be  available  to  show   the  syntax  of   the  translations. 

The  code  is  derived  from   the  design  and     specification     components 
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which  are  now  available  for  analysis.  The  coding  of  the  sample  problem 
is  Illustrated  below  into  the  language  WBASIC.  The  analysis  of  the  rea- 
soning is  left  to  the  reader. 

Diagram  fl.lla  -   Coding  of   Sample  Problem 
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COSTOMER   NUMBER    :    ; 


%     DATE    :   % 


%' 


HEMIZED  BILL' 
NOMBEH   CALLED  TIME        MINUTES  COST' 


*   % 


titti       Hit 


fttt.ti' 


HEM  PROGRAM  PHONE_BILL 

HEM     INITIALIZE  ACCUMULATORS   AND  SELECTORS 

IN_AREA_COUNT  =   0 

001LAREA_COUNT  =   0 

I11_AHEA_CALU.C0ST     =   0.0 

001L.AREA_CALL_C0ST  =0.0 

CURRENT_LABGE_CALL  =   0.0 
I 

REM     INITIALIZE  FORMATS    AND  HEADINGS 
1 

REM     1231567890123156789012315678901231567890123111567890 
F1$='  MDH    PHONE  COMPANY' 

REM     1 

F2$: 

REM 

F3$  = 

REM 

F1$= 

REM 

F5$  = 

REM 

REM 

F6$  = 

F7$  = 

REM 

F8*= 

F9$= 

REM 

Gl$  = 

G2$  = 

REM 

G3$  = 

REM 

G1$  = 

G5$  = 

G6$  = 

REM 

07$= 

1 

REM 

I 


YOUR  HOST  EXPENSIVE  CALL   WAS   TO  % 
AND  COST  mt.fi' 


NUMBER   OF 
CALLS 


COST 


IN    AREA 
OUT  AREA 


an 

ttti 


Hit.  ti 
tiii.tt 


SUMMARY 


mt 


STATE  TAX 
FEDERAL    TAX 
SERVICE   CHARGE 


tmt.  it 

tttt.it 

tttt.tt 

itt.tt 


PAY  THIS   AMOUNT 


tittt.it 


PROCESSING 
READ  HEADER   RECORD 
READ  CUS_AREA_CODE$,    CUS_HUHBER$,    SEHVICE_CHARGE 
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2030   !  BUILD  CDSTOMEH    PHONE  FOR  DISPLAY 

2040  COS_NUILDISFLAY$   =    '(•   +  CUg_AREA_CODE$   +   •)    '   + 

STH$   (   C05_N0MBEH$,    1,3)+'-'   + 
STR$   (   C0g_N0HBER$,   K ,   1)) 

2050    !  PRINT  TOP  HEADING 

2070  PRINT  F1$ 

2080    I  PRINT  LINE 

2090  PRINT  HPT$('-',   1|9) 

2100    I  PRINT  COSTOMER   DETAIL  LINE 

2110  PRINT  OSING   F2$,    COg_NUM.DISPLAY$,    DATE$ 

2120    !  PRIMT  LINE 

2130  PRINT  RPT$('-',   1I9) 

2110    I  PRINT  REPORT  TOP  HEADING 

2150  PRINT  F3$ 

2160  PRINT 

2170   I  PRIKT  COLOMJ   HEADING 

2180  PRINT  Fl|$ 

2190    1  PRINT  LINE 

2200  PRINT  SPT$('-',ll9) 

2205    ! 

2210    I  INITIALIZE  CALL  LOOP  BY  READING    CALL    RECORD 

2220  HEAD  REC_AREA_CODE$,    REQ_NUMBER$,    TIME_OF_CALL$, 
SECONDS_OF_CALL 

2230   I 

2210    !  WHILE  NOT  SENTINEL    RECORD 

2260  WHILE   (HEC_AREA_CODE$   <>    'TRASH') 

2270   I  CALCULATE  MINDTES   OF  CALL 

2280  MINDTES  =    SECONDS. OF_CALL  /   60.0 

2290    I 

2300   1  IF  CALL   IS   IN    AREA  THEN 

2310  IF  (REq_AREA_CODE$  =   C0g_AREA_C0DE$) 

2320    I  SET   AREA  DISPLAY  TO  BLANK 

2330  AREA_DISPLAY$  =    '    ' 

2310    I  CALCULATE  CALL    COST 

2350  CALI^COST  =   MINUTES_OF_CALL    •  .20 

2360   1  BUILD  CALL   NUMBER   FOR   DISPLAY 

2370  CALL.NOH.DISPLAY$   =    '             •    + 

STH$(REq_N0MBER$,1,3)    + 

'-'    +  STR$(REQ.NUMBER,    H ,   1| ) 

23  80    I  INCREMENT  IN    AREA  COUNT 

2390  IN_AREA_COUNT  =    IN_AREiL  COUNT  +   1 

2100    1  ACCUMULATE   IN   CALL   COST 

2110  IN_AREA_COST  =    IN_AREA_C0ST  +   CALI^COST 

2120  Q.SE 

2130  SET  AREA  DISPLAY  TO    '0' 

2110  AREA_DISaAY$  =    '0' 

2150    1  CALCULATE   CALL   COST 

2160  CALL^COST  =   MINUTES_OF_CALL    •  ,21 

2170   I  BUILD  CALL   NUMBER   FOR  DISPLAY 

2180  CALL_NU^LDISaAYt   =    '('   +  REC_AREiLCODE$     +   •)    • 

STR$(REq_NUMBER$,1,3)    + 
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'-•   +  STR$(REC_HUMBEH,    H,   I) 

21(90    I  INCREMENT  OUT  AREA   COUNT 

2500  0OX.AHEA_COONT  =    OUILAREA.  COUNT  +   1 

2510    I  ACCOMULAIE   OUT  CALL    COST 

2520  001LAREA_C0ST  =    OUX_AREA_COST  +   CALU_COST 

2530  ENDIF 
25140    ! 

2550  BUILD  TIME   OF  CALL   FOR   DISPLAY 

2560  TIME_DISPLAY$   =  STR$(TIMEi_OF_CALL$,    1,2)    +   ':•   + 

STR$(TIME_OF_CALL$,    3,   2) 

2570   I  PRINT  DETAIL  LME 

2510  PRINT  USING   F5$,    AR  EA_DIS  PL  A  Y$ ,    CALL_NOM_DISPLAY$, 

TIME_DISaAY$,    MINUTES_OF_CALL,    CALL   COST 
2550    I 

2560   !  IF  COST  OF  THIS   CALL    IS  GREATER    THAN   LARGEST  THEN 

2570  IF  CALI^COST  >  CURRENT_LAEG_CALL 

2580    1  SET  LARGEST  CALL    COST  TO   THIS   COST 

2590  CDRREN'ILLARG_CALL  =    CALL_COST 

2600    I  SET  LARGEST  CALL   NUMBER    TO   THIS   NUMBER 

2610  CnRREN'!LLAHG_NOM$   =   CALI^NUH.DISPLAY$ 

2620  ENDIF 
2630   I 

261)0    I  UPDATE  CALL  LOOP  BY  READING    NEXT  RECORD 

2650  READ  REC_AREA_CODE$,    HEQ_NOMBER$,    TIME_OF_CALL$, 

SECONDS.  OF_CALL 

2660  ENDLOOP 
2270   I 

2280    I  PRINT  LINE 

2290  PRINT  RPT$('-',1I9) 

2300   I  PRINT  LARGEST  COST  LINES 

2310  PRINT  USING   F6$,    CURRENX_LARG_NUM* 

2320  PRINT  USING    F7$,    CURRENT_LARG_CALL 

23110    I  PRINT  SUMMARY  HEADINGS 

2350  PRINT 

2360  PRINT  F8$ 

2370  PRINT  F9$ 

2380    I  PRINT  LINE 

2390  PRINT  RPT$('-',   HI) 

21100    I  PRINT  IN    AREA  SUMMARY 

2H10  PRINT  USING   G1$,    IN_AREA_ COUNT,    IN_AREiLCOST 

21120    I  PRINT  OUT  AREA  SUMMARY 

21130  PRINT  USING   G2$,    OUTLAHEA. COUNT,    OU T_ AH EA_ COS T 

21*1)0    !  PRINT  LINE 

21)50  PRINT  RPT$('-',   D1) 

21)60    I  CALCULATE   TOTAL   CALL   COUNT 

21)70  RECOHD_COUNT  =    IN_AREA_COaNT  +   OUX_AREA_COUNT 

21)80    I  CALCULATE  TOTAL    CALL   COST 

21)90  TOTAL_CALL^COST  =    IN_AREA_COST  +   OUT_AREA.COST 

2500    I  PRINT  TOTAL   CALL   SUMMARY 

2510  PRINT  USING   G3$,    RECOHD_ COUNT,    TOTA:^CALL_COST 

2520    I  CALCULATE  STATE  TAX 

2530  STATE. TAX  =  TOTAL. CALL_ COST   •  .03 
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2510    I  CALCULATE  FEDERAL   TAX 

2550  FEDERAL. TAX  =  00 T_ AREA. COST   •  .Oil 

2560   1  CALCULATE   AMOUNT  TO  BE   PAID 

2570  CO^COST  =   TOTAL_CALL_COST  +   SERVICE.  CHARGE 

+   STATELTAX   +  FEDERAL_TAX 

2580    I  PRINT  STATE   TAX  LINE 
2590  PRINT  USING   Gl|$,    STAT^TAX 

2600    1  PRINT  FEDERAL   TAX  LINE 
2610  PRINT  USING   G5*,    FEDERAI^TAX 

2620    I  PRINT  SERVICE   CHARGE  LINE 
2630  PRINT  USING   G6$,    SERVICE. CHARGE 

26H0    !  PRDIT  LIKE 
2650  PRINT  RPT$('-',   HI) 

2660   1  PRINT  AMOUNT  TO  BE   PAID  LIME 
2670  PRINT  USING   G7$,    CHg.COST 

26  80      STOP 


The  above  coding  is  the  translation  of  the  specification,  design, 
and  preceding  components  into  the  language  WBASIC.  The  coding  phase 
follows  the  design  component  directly.  The  students  need  to  be  able  to 
hand  code  a  solution  using  the  necessary  keywords  from  the  language  and 
the  user  defined  identifiers  from  the  pre-coding  phase.  The  goal  at 
this  point  is  to  have  a  hand-written  program  that  is  close  to  the 
desired  solution.  This  coding  is  now  input  to  the  testing  phase  for 
debugging  and  verification. 

lt.5  Testing  Phase 

Upon  the  completion  of  the  coding  phase,  the  solution  has  been 
coded  into  a  high-level  language.  This  coding  is  now  submitted  to  the 
testing  phase  of  the  analytic  problem  solving  process.  The  testing 
phase  includes  the  removal  of  language  syntax  errors  and  the  verifica- 
tion of  the  output  that  is  produced  with  the  desired  postcondition  of 
the  output  from  the  specification  phase.  This  verification  includes  the 
correctness  of   the  output  values  and  the  physical   form  of   the  output. 
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The  first  step  in  the  testing  phase  requires  the  students  to  enter 
the  coded  program  using  a  system  editor.  Next  the  source  file  should 
be  submitted  to  the  compiler  or  interpreter  for  debugging.  The  result 
is  then  analyzed  by  the  students.  Based  upon  their  analyses,  the  sys- 
tem editor  is  used  again  to  make  the  necessary  changes.  The  students 
repeat  these   steps  until   the  desired  postconditions  are  achieved. 

A  correctly  tested  program  will  contain  no  syntactical  errors  and 
Mill  produce  correct  output.  This  phase  is  frustrating  for  the  begin- 
ning students  because  the  debugging  of  errors  takes  experience.  The 
students'  understanding  of  syntactical  forms  and  their  ability  to  hand 
synthesize  code  are  very  necessary  concepts  to  support  this  phase.  The 
availability  of  the  instructor  and  laboratory  help  can  greatly  reduce 
the  students'   anxiety  in  the  beginning. 

In  this  report  no  attempt  is  made  to  define  the  methods  in  the 
testing  phase.  It  is  only  important  for  the  reader  to  understand  the 
desired  result  of  this  phase  and  its  importance  in  the  problem  solving 
process.  If  careful  development  of  the  program  is  undertaken,  the 
testing  phase  can  be  minimized.  The  magnitude  of  effort  that  is 
required  in  this  phase  is  inversely  proportional  to  the  amount  of 
abstract  verification  effort  in  the  previous   phases. 

4.6  Documentation  Phase 

The  final  phase  in  the  analytic  problem  solving  process  is  the 
documentation  of  the  verified  solution.  Documentation  actually  occurs 
all   through   the  analytic  problem     solving     process.      The     specification 
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phase  involves  the  documentation  of  the  precondition  and  postcondition 
of  the  formal  analytic  problem.  The  design  phase  involves  the  documen- 
tation of  the  design  of  a  solution  to  the  problem.  The  coding  phase 
requires  the  students  to  document  the  instructions  or  the  actions  Into 
a  high-level  language.  This  coding  by  hand  is  normally  discarded  as 
documentation  because  the  actual  source  code  that  is  entered  in  a  file 
replaces  it.  However,  the  student  is  asked  to  include  additional  docu- 
mentation during  the  documentation  phase. 

One  form  of  documentation  the  students  must  generate  during  this 
phase  is  the  global  header  block  at  the  top  of  the  program.  The  form 
of  this  documentation  can  vary  based  on  the  instructor's  desired  form; 
but  a  sample  form  is  presented  in  this  report.  The  inclusion  of  the 
documentation  is  felt  to  be  a  necessary  component  in  the  final  solution 
for  maintenance  at  later  stages  in  the  life  of  the  software  solution. 
Diagram  #l|.6a  illustrates  one  possible  form  of   the  global   header   block. 

Another  form  of  documentation  that  the  student  may  need  to  gen- 
erate is  a  user  manual  for  the  software  package.  Such  a  user  manual 
could  include  a  definition  of  the  purpose  and  use  of  the  package  and 
include  a  tutorial  for  entering  the  data  and  bow  to  execute  the  program 
once   the  data  is  entered. 

Other  forms  of  documentation  at  this  point  could  be  internal  com- 
ments within  the  program  to  break  up  the  basic  parts  of  the  source 
code.  The  students  can  be  asked  to  document  to  any  level  of  abstraction 
that  Is  required  by  the  Instructor.  The  Important  factor  Is  that  the 
students  have     access     to     illustration     material     which     contains     the 
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goo   REM  PHONE  EILL 

910    I 

920    !  PHOGRAMMEH                 :   MICK  HANEY 

930   I  DEVELOPMENT  DATE    :    11/11/86 

935    I  LANGOAGE                     :  HBASIC 

910    I  PBHPOSE                       : 

950    1 

960   1  TO   PROCESS   A  PHONE  BILL   FOR   AN    INDIVIDUAL   OSING    IHE 

970   I  MELTON,    ONGER,    WALLENTINE   PHONE  COMPANY. 

980    I 

990    1  EXTERNAL   DO  CO  MENTATION    : 

900   I 

910    I  AVAILABLE  IN   FOLDER  -    PHONE  BILL 

920    I 

930   I  DATA  DICTIONARY 

910    1 

950    I  INPUT  VARIABLES 

960   I  CU5_AREA_C0DE$ area  code   of  ouatomer 


Diagram  tH.6sL  -   Possible  Global   Header  Block 

desired  form  and  level   of  abstraction  in  the  documentation. 

4.7   C<?ll<;Avi3ioq  ^  Analytic  IraHiSB  .SslllLB  Process 

The  above  analytic  problem  solving  process  defines  the  steps 
necessary  to  completely  specify  the  solution  to  a  formal  analytic  prob- 
lem. The  students  were  asked  to  specify  the  pre-  and  postconditions  of 
a  given  analytic  problem  and  then  specified  the  actions  to  perform  the 
translation.  The  introduction  of  this  defined  process  provides  three 
basic  benefits  in  the  course  design.  First,  it  provides  the  instructor 
with  an  illustration  method  for  the  development  of  analytic  solutions. 
Second,  it  provides  the  student  with  a  defined  synthetic  process  to  use 
in  solving  assigned  problems.  Third,  it  provides  a  format  for  complete 
testing  of  analytic  problem  solving  ability. 
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CHAPTER  5 
IMPLEMENTATION    OF  THE  COURSE 


In  Chapter  One  two  basic  assumptions  were  asserted.  First,  tbe 
students  were  unable  under  more  traditional  methods  of  teaching  CS1  to 
solve  formal  analytic  problems.  Second,  the  instructor  lacked  a  method 
to  teach  these  students  to  solve  sucb  problems.  Tbe  goal  in  this 
chapter  is  to  define  a  course  design  that  concentrates  on  the  teaching 
and  student  developnent  of  solutions  to  analytic  problems.  Briefly, 
the  first  step  in  the  course  design  is  to  teach  the  students  the 
defined  problem  domain.  In  addition,  the  development  of  analytic  solu- 
tions is  illustrated.  Also,  tbe  students  are  asked  to  solve  problems 
witbin  tbe  defined  problem  domain.  This  chapter  is  devoted  to  describ- 
ing a  course  which  concentrates  on  illustrating  the  complete  develop- 
ment of  analytic  solutions  both  in  presentation  by  the  instructor  and 
development  by  tbe  students.  The  three  basic  phases  of  the  proposed  CS1 
course  are  explained  in  detail  below.  In  addition  a  formal  method  of 
testing  the  comprehension  of   analytic  skills  is  described, 

5.1    Phase  One 

Tbe  first  phase  in  the  proposed  course  design  includes  tbe  follow- 
ing msijor  objectives: 

(1)  An  overview  of  tbe  system  that  the  student  will  use  in 
testing  solutions  to  analytic  problems; 

(2)  An  overview  of  the  defined  problem  domain  including  the 
physical  processing  configuration  and  reverse  analysis  of 
the  necessary  abstract  analytic  components;   and 

(3)  An  overview  of  the  language  to  be  used  in  implementation 
of   analytic  solutions. 
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The  first  major  objective  of  this  phase  in  the  course  is  to  teach 
the  students  to  use  the  computer  system  to  be  used  in  the  testing  phase 
of  the  analytic  problem  solving  process.  For  example,  the  students 
should  be  taught  to  logon  the  system,  execute  the  necessary  operating 
system  commands,  and  use  the  necessary  tools  such  as  editors  and  compi- 
lors.  The  students  should  perform  a  lab  assignment  that  tests  the 
achievement  of   this  objective. 

The  second  major  objective  is  the  teaching  of  the  defined  problem 
domain  consisting  of  the  physical  processing  configuration  and  the 
necessary  abstract  analytic  components.  The  method  of  teaching  the 
defined  problem  domain  is  chalkboard  execution.  Further  explanation  of 
this  method  is  contained  in  the  appendices.  In  this  method  the  lab 
assignment  program  that  was  entered  and  executed  for  teaching  the  sys- 
tem objective  should  be  used.  This  set  of  code  is  hand  executed  on  a 
chalkboard  by  the  students  as  a  class  to  Illustrate  both  the  physical 
processing  configuration  and  the  procedural  and  data  abstraction  abili- 
ties Hithin  the  configuration.  After  board  executing  the  set  of  code 
several  times,  the  students  begin  to  derive  through  instructor  guidance 
the  procedural  abilities  through  reverse  analysis.  For  instance,  the 
students  will  see  after  several  board  executions  that  a  statement  of 
the  form  X  =  X  +  Y  used  within  a  loop  accumulates  the  value  Y.  Thus 
through  reverse  analysis,  the  abstract  design  primitives  are  derived, 
and  also  the  concept  of  data  abstraction  and  instantiation  is 
developed. 

The  third  major   objective  of  this  phase  is  to  give  the  students  an 
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overview  of  tbe  higb-level  language  to  be  used  in  Implementation  of 
analytic  solutions.  This  overview  should  illustrate  the  program  struc- 
ture, statements,  and  the  respective  syntax  that  is  associated  with 
these  statements.  If  the  lab  assignment  program  utilized  to  teach  tbe 
system  objective  is  prepared  so  that  all  statements  that  are  necessary 
at  this  level  of  programming  are  used,  the  instructor  has  access  to  a 
strong  aid  for  illustrating  program  structure  and  the  statements  within 
the  program.  A  large  amount  of  time  should  not  be  spent  on  memoriza- 
tion of  syntax.  The  goal  is  to  solve  analytic  problems,  and  the  learn- 
ing of  syntax  Is  Inherent  through  using  the  language  as  a  final  imple- 
mentation of  the  solution  and  availability  of  sample  code. 

After  the  completion  of  the  first  phase,  the  students  have  experi- 
enced the  entering  and  executing  of  a  program  in  a  certain  language  and 
in  a  certain  system  environment.  The  students  should  also  have  an 
abstract  view  of  how  the  program  works  in  terms  of  the  input  file,  out- 
put file,  and  global  memory  components  of  the  physical  processing  con- 
figuration. The  students  should  begin  to  think  of  data  in  terms  of  tbe 
actual  instantiation  and  the  abstraction  of  data  into  semantic  descrip- 
tors. In  addition,  the  students  should  be  able  to  understand  the 
nature  of  the  procedural  abilities  necessary  to  solve  analytic  prob- 
lems. Lastly  the  students  should  have  an  understanding  of  tbe  general 
form  of  a  program  and  the  use   of   statements  in  that   program. 

5.2   Phase  Two 

The  first  phase  presented  the  students  with  an  understanding  of 
tbe     computer     system,      the  defined  problem  domain,    and  an  overall   view 
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of  tbe  language  tbat  is  to  be  used  in  ImplenentaUon.  In  tbis  second 
pbase  tbe  students  begin  to  solve  formal  analytic  problems,  Tbe  objec- 
tives of  tbis  pbase   are  as  follows: 

(1)  To  introduce  tbe  students  to  tbe  analytic  problem  solving 
process; 

(2)  To  teacb  the  use  of  certain  procedural  primitive  abili- 
ties introduced  during  the  first   pbase   of   the  course;  and 

(3)  To  use  tbe  analytic  problem  solving  process  to  solve  for- 
mal analytic  problems  containing  tbe  procedural  primitive 
abilities  referred  to  above. 

Tbe  introduction  of  tbe  analytic  problem  solving  process  described 
in  Chapter  Four  is  tbe  first  objective  in  this  second  phase.  The  stu- 
dents need  to  understand  what  an  analytic  problem  is  and  the  method 
tbat  will  be  used  to  solve  these  problems,  A  handout  illustrating  the 
workings  of  the  analytic  problem  solving  process  should  be  made  avail- 
able to  the  students. 

The  second  major  objective  in  pbase  two  are  tbe  teaching  of  the 
concepts  of  sentinel  file  input,  formatted  file  output,  and  Internal 
arithmetic  processing.  The  file  input  requires  tbe  concept  of  repeti- 
tion using  the  sentinel  value  technique.  The  arithmetic  processing 
includes  tbe  primitive  concepts  of  calculation  based  on  one  record, 
accumulation,  increment,  summary  calculation,  and  formatted  output 
using  the  print  primitive.  Using  board  execution  In  the  previous  phase 
should  already   have  introduced  the  student   to  these  concepts. 

Tbe  third  major  objective  in  tbis  pbase  is  for  the  students  to  be 
able  to  develop  a  solution  to  an  analytic  problem  tbat  contains  the 
above  concepts  using  tbe  formal   analytic  problem  solving     process.      Tbe 

Page  59 


solving  of  an  analytic  problem  should  illustrate  the  desired  conceptual 
primitives  and  the  ability  to  formally  derive  the  solution  to  this 
problem.  The  method  suggested  is  simply  for  the  instructor  to  present 
an  analytic  problem  that  contains  the  desired  concepts  and  to  use  the 
above  synthetic  model  to  solve  the  given  problem.  In  working  this 
problem,  the  illustration  of  all  reasoning  for  the  development  needs  to 
be  provided  by  the  instructor.  Performing  the  above  task  illustrates 
the  development  of  a  solution  to  an  analytic  problem  using  the  problem 
solving  process  and  also  illustrates  the  desired  procedural  primitives 
and  data  abstraction. 

The  testing  Nithin  this  phase  should  be  the  assignment  of  an  ana- 
lytic problem  that  contains  the  same  concepts  that  were  illustrated  in 
the  instruction  example.  The  students  should  be  forced  to  use  the  prob- 
lem solving  process  to  solve  the  assigned  problem.  Each  step  in  the 
process  needs  to  be  verified  by  the  instructor  before  the  student  is 
allowed  to  continue.  Several  class  periods  can  be  dedicated  to  the 
verification  by  the  instructor  of  each  individual  phase  of  the  process. 
The  goal  of  the  lab  is  to  implement  solutions  to  analytic  problems.  The 
solution  is  not  Just  the  program.  It  also  includes  the  specification  of 
pre-   and  postconditions  and  the  derivation  of   the  actions. 

The  result  of  this  phase  is  the  exposure  of  the  student  to  the 
complete  development  of  two  analytic  solutions  that  contain  the  desired 
procedural  primitives,  data  abstraction,  and  the  use  of  a  computer  sys- 
tem for  verification  of  that  solution.  Remember  that  the  teaching  of 
the  solving  of   analytic  problems  was  stated  in  Chapter   One     as     one     of 
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the  major  factors  necessary  in  the  teaching  of  CS1  students;  and  using 
the  above  method  illustrates  twice  the  development  of  analytic  solu- 
tions. 

5.3   Phase  Three 

The  second  phase  illustrated  the  analytic  problem  solving  process, 
the  procedural  primitive  abilities  including  file  processing,  formatted 
output,  and  arithmetic  abilities,  and  data  abstraction.  In  this  third 
phase  the  ability  to  make  decisions  as  to  what  processing  is  to  occur 
is  added  to  the  concepts  presented  in  phase  two.  The  objectives  of 
this  phase  are  as  follows: 

(1)  To  introduce  the  students  to  the  decision  primitive 
explained  in  3.2.2.2   of   this  report; 

(2)  To  introduce  the  students  to  the  selection  primitive 
explained  in  3.2.2,3   of   this  report; 

(3)  To  introduce  the  students  to  the  Set,  Build,  and  Extract 
design  primitives  explained  in  3.2.2.4  of  this  report; 
and 

(1)  To  introduce  the  students  to  the  nesting  of  the  decision 
primitive. 

The  first  objective,    which  is  the     introduction     of     the     decision 

primitive,     allows  the  student  to  control  which  other  primitives  are  to 

be  executed.    The  result  is  that  the  students  can  now   vary   the  method  of 

Instantiation     of     a     semantic     descriptor   and  also   can  now   instantiate 

more  detailed  semantic  descriptors.    For  instance,    the  students  can     now 

instantiate     the  call   cost   using  different  rates  and  can  count   both   the 

Ir^area  and  out-area  calls  in  the  sample  problem     in     Chapter     Four     of 

this  report  by  using  a  decision  structure. 
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The  second  major  objective  of  the  third  phase,  which  ia  the  intro- 
duotion  of  the  selection  primitive,  allows  the  students  to  select  the 
largest  and  smallest  instantiation  of  a  semantic  descriptor  during 
repetition.  This  primitive  is  designed  using  the  decision  primitive  and 
therefore  ia  procedurally  achievable  after  the  decision  structure  has 
been  introduced. 

The  third  objective  of  this  phase  is  the  introduction  of  the  Set, 
Build,  and  Extract  procedural  primitives.  These  primitives  allow  the 
students  to  perform  operations  on  character  data.  The  operations  on 
character  data  include  the  expanding  or  extraction  of  a  string  of  char- 
acters to  instantiate  a  new   string  of   characters. 

The  last  major  objective  in  this  phase  is  to  teach  the  student  to 
nest  decision  structures.  This  concept  expands  the  use  of  the  decision 
structure  to  multiple  use  of  the  structure  within  the  true  or  false 
side   of   a  decision  structure. 

The  implementation  of  this  phase  is  done  in  four  parts.  The 
instructor  will  introduce  an  analytic  problem  that  contains  a  single 
decision  structure  and  uses  the  analytic  problem  solving  process  to 
derive  the  coded  solution.  The  students  are  then  assigned  a  similar 
analytic  problem  and  asked  to  use  the  analytic  problem  solving  process 
to  derive  a  tested  and  documented  solution.  Next  this  process  is 
repeated  using  analytic  problem  which  requires  the  nesting  of  deci- 
sions. 

The  results  of  the  third  phase  is  the     students     exposure     to     the 
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procedural  oonoepts  from  the  previous  phases  with  the  addition  of  the 
decision  structure  and  the  detailed  generation  of  values  that  are  asso- 
ciated with  the  decision  structure.  The  oonoepts  of  selection  and 
string  processing  have  been  introduced.  The  students  have  now  been 
exposed  to  the  complete  development  of  the  solution  to  six  analytic 
computer  problems  and  formal  testing  of  transfer  of  this  ability  should 
be  occur. 

5.1   Testing 

The  above  phases  cover  one  half  of  a  semester  to  teach  the  content 
of  CS1.  At  this  point  in  time  a  midterm  test  is  Induced  to  test  the 
competence  of  the  students  in  developing  solutions  to  analytic  problems 
within  the  defined  problem  domain  form  Chapter   Three. 

The  method  suggested  for  testing  comprehension  of  the  primitive 
concepts  and  the  students  ability  to  solve  analytic  problems  is  to 
induce  an  analytic  problem  which  necessitates  the  use  of  all  analytic 
abilities  in  the  problem  domain  and  the  derivation  of  the  solution 
using  the  analytic  problem  solving  process.  The  form  of  the  test 
should  be  available  to  the  student  at  the  beginning  of  the  semester  for 
viewing  and  proper  preparation.     The  suggested  time  limit  is  two  hours. 

5.5  Conclusion 

The  above  phases  present  a  possible  implementation  of  a  CS1  course 
which     concentrates     on     the  complete  derivation  of   analytic  solutions. 
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Through  the  implementation  of  the  above  course  design  the  students  are 
exposed  to  six  complete  derivations  to  analytic  problems  within  the 
defined  problem  domain.  Three  of  these  exposures  were  illustrated  by 
the  instructor  and  three  by  the  students  in  preparation  for  formal 
testing.  The  phases  are  progressive  in  terms  of  problem  complexity  and 
follOH   the  content   of   the  text   [3]. 
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CHAPTER  6 
CONCLUSION 


The  problem  that  this  paper  addressed,  as  defined  in  chapter  one, 
was  to  create  a  learning  enrironment  where  tbe  average  high-school  stu- 
dent could  succeed  in  solving  formal  analytic  problems  in  tbe  course 
CS1.  To  create  this  environment  three  basic  components  were  intro 
duced.  First,  a  problem  domain  was  defined  which  included  the  physical 
processing  configuration  and  the  abstract  analytic  abilities  necessary 
to  solve  problems  within  the  domain.  Second,  an  analytic  problem  solv- 
ing process  was  defined  for  consistent  instructor  illustration  and  con- 
sistent student  development  of  analytic  solutions  within  tbe  defined 
problem  domain.  Third,  a  course  design  was  defined  wbich  concentrated 
on  illustration,  development,  and  testing  of  the  complete  process  of 
solving  analytic  problems. 

The  above  components  wben  combined  together  present  a  course 
design  which  structures  the  introductory  students'  initial  experience 
in  solving  formal  analytic  problems  in  computer  science.  Upon  comple- 
tion of  the  course  design  in  this  paper  the  students  need  to  be  intro- 
duced to  toi>-down  design.  Further  research  is  necessary  in  this  method 
to  extend  the  problem  domain,  the  analytic  problem  solving  process  to 
include  toi>-down  design  for  decomposition  of  more  complex  analytic 
problems,    and  the  course  design  to  support  these  necessary   objectives. 
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APPENDIX  A 
CHALKBOARD  EXECUTION 


The  first  phase  of  the  course  In  this  paper  refers  to  a  method 
Nbicfa  uas  called  chalkboard  execution.  This  appendix  Is  a  definition  of, 
that  method.  The  purpose  of  the  method  Is  to  illustrate  the  separation 
and  interaction  of  of  the  physical  processing  configuration,  to  illus- 
trate the  synthesis  of  data  through  the  physical  processing  configura- 
tion, and  to  allow  for  reverse  analysis  of  the  abstract  analytic  abili- 
ties. 

INITIALIZATION 

The  necessary  physical  tools  are  the  availability  of  a  chalk  board 
and  a  common  set  of  high-level  source  code  that  contains  the  desired 
processing  concepts.  The  board  is  divided  into  three  separate  areas 
representing  the  physical  processing  configuration.  One  board 
represents  the  input  file  component,  one  represents  the  global  memory 
component  and  one   board  represents  the  output  file  component. 

The  input  data  is  initially  placed  in  the  board  section  dedicated 
to  the  input  file  component.  The  data  should  be  in  the  same  form  that 
Is  needed  in  the  specific  language.  An  arrow  is  positioned  before  the 
first  Item  In  the  Input  file  and  represents  the  intrinsic  file  pointer. 
After  each  successive  field  is  read  this  data  pointer  is  moved  to  the 
next  field  of  data.  The  postcondition  of  the  input  file  component  In 
the  specified  environment  states  that  all  records  will  have  been  read 
and  the  data  pointer   should  end  up  after   the  sentinel   record. 
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Tbe  global  memory  component  board  Is  Initially  clear  because 
before  the  activation  of  the  module  of  code  no  reference  to  the  inter- 
nal memory  exists.  At  the  completion  of  tbe  module  the  memory  area 
should  be  erased  because  at  tbe  termination  of  the  global  module  all 
reference  to  Internal  memory  is  lost, 

Tbe  output  board  is  initially  clear  also.  The  precondition  of  the 
output  file  is  simply  that  the  file  exists  and  we  assume  that  tbe  file 
is  empty.  Tbe  postcondition  of  the  output  file  uill  contain  the  output 
from  the  module  that  is  to  be  synthesized  using  tbe  data  In  tbe  Input 
file. 

BOAHD  EXECOTION 

Given  tbe  Initial  board  setup,  tbe  common  set  of  code  is  to  be 
synthesized  on  the  board  by  tbe  students  performing  one  elemental  func- 
tion per  person  and  moving  tbe  responsibility  around  the  room.  Verifi- 
cation of  actions  that  are  performed  by  the  students  is  necessary  by 
tbe  instructor  and  guidance  is  required  when  necessary.  At  critical 
points  in  tbe  execution  the  instructor  can  discuss  the  present  state  of 
tbe  synthetic  process. 

He  begin  by  starting  at  the  top  of  the  program  and  executing 
Instructions  in  the  logical  order  that  tbe  computer  would  use.  In  a 
compiled  language  the  first  section  of  code  will  be  the  declaration  of 
variables.  When  this  is  arrived  at  in  tbe  code  each  student  should 
draw  a  box  in  the  memory  area  and  label  the  box  outside  with  the  name 
and     type     of     the  location.    The  box  should  not  contain  a  value   because 

Page  6  8  :     .     ,. 


the  creation  of  a  location  does  not  necessarily  define  it.  Variable 
gain  a  value  initially  when  used  in  a  read  statement  or  on  the  left 
band  of   an  assignment   statement. 

In  an  interpreted  environment  the  variables  are  not  created  until 
the  variable  is  used  In  the  code.  The  creation  of  variables  in  this 
enviroiment  occurs  when  the  student  goes  to  execute  bis  instruction  and 
there  exists  no  variable  in  the  global  memory  component  that  is  to  be 
defined.  In  the  Interpreted  environment  the  student  performs  both  a 
variable  creation  and  an  instruction  execution. 

We  then  move  to  the  execution  of  the  actual  instructions  in  the 
body  of  the  code.  The  read  statement  takes  the  next  value  in  the  Input 
file  and  places  it  in  some  variable  in  the  memory  section.  The  data 
pointer  is  advanced  by  this  same  student  to  the  next  item  in  the  input 
file.  In  reading  a  record  I  let  one  student  read  one  field  and  not  the 
whole  record.  The  Importance  of  this  is  that  the  student  sees  that  the 
computer  reads  the  data  one  field  at  a  time  and  an  error  can  occur  in 
the  middle  of   a  read  statement. 

The  write  statement  takes  values  from  variables  in  the  global 
memory  component  along  with  program  annotation  and  transfers  them  to 
the  output  file  component.  The  implementation  again  here  is  to  allow 
one  student  to  transfer  one  field  to  the  output  to  show  that  an  error 
can  occur  in  the  middle  of  a  write  statement.  At  this  time  the  format- 
ting in  the  language  can  be  discussed.  This  discussion  can  also  be 
deferred  to  the  second  session  of  board  execution. 
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The  arithmetic  statements  use  variables  in  the  memory  and  program 
constants  to  assign  a  value  to  another  variable  in  the  memory  area.  If 
arithmetic  Is  necessary  a  part  of  the  memory  board  is  dedicated  the  ALU 
in  which  the  student  must  perform  the  computation.  The  student  should 
perform  the  computation  and  place  the  result  in  the  variable  that  is 
assigned, 

Ue  do  not  represent  effects  by  conditional  statements  on  the 
board.  Each  time  we  arrive  at  one,  the  teacher  discusses  the  condition 
in  terms  of  the  present  state  of  the  memory  component  and  the  class 
decides  whether  it  evaluates  to  true  or  false.  Upon  this  decision  the 
next  student  executes  the  respective  statement  depending  on  the  condi- 
tion. 

STOP  STATE 

At  the  termination  of  the  module  the  last  thing  to  occur  is  the 
erasing  of  the  internal  memory  by  a  student.  This  represents  the 
abstraction  that  the  variables  in  memory  are  dereferenced  upon  the  ter- 
mination of  a  module.  The  data  pointer  in  the  Input  file  should  be 
pointing  past  the  sentinel  record.  The  only  thing  that  remains  that  is 
different  from  the  precondition  of  the  board  Is  the  output  that  is  gen- 
erated in  the  output  file. 

CONaOSION    AND  CONCEPTS 

The  use  of  this  method  is  further  enhanced  If  the  code  used  is  the 
same     assignment     that     the     student     used     In  the  system  exercise.    The 

Page  70 


student  has  entered  and  executed  this  set  of  code  and  achieved  the  out- 
put. The  output  on  the  board  should  be  the  same  output  that  was  submit- 
ted by  the  student  In  the  lab  assignment.  This  leads  the  student  to  a 
strong  understanding  what  the  program  that  was  used  in  the  system  lab 
did. 

The  concepts  that  can  be  illustrated  using  this  method  are  only 
limited  by  the  instructors  initiative  to  stop  during  execution  and  dis- 
cuss the  states.  The  student  should  see  the  separation  of  the  input 
file,  output  file,  and  internal  memory  components  and  gain  an  under- 
standing of  how  they  Interact.  They  see  that  a  value  cannot  go  directly 
from  the  input  file  to  the  output  file  without  first  being  stored  in 
memory.  They  see  how  values  can  be  generated  using  other  values  and 
program  constants  and  that  this  instantiation  can  be  stored  in  a  memory 
location. 

One  session  of  board  execution  is  not  felt  to  be  enough  to  allow 
the  student  complete  comprehension  of  the  processing  environment.  On 
the  second  time  through  the  student  sees  the  processing  again  and  prob- 
ably retains  more  knowledge.  The  third  effort  can  be  done  using  a  dif- 
ferent  set  of   code   to  get  rid  of  the  monkey   see  monkey  do  aspect. 

The  method  also  allow  the  student  to  get  out  of  the  chair  and  per- 
form in  front  of  peers.  This  can  induce  laughter  but  can  also  be  frus- 
trating for  some  students  and  requires  careful  guidance  and  motivation 
on  the  instructors  part.  This  is  not  to  say  that  the  instructor  cannot 
bust  a  student  in  the  chops  with  a  Joke  or  two  for  performing  the  wrong 
task. 
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ABSTRACT 

More  and  more  students  are  enrolling  in  introductory  programming 
courses  at  the  secondary  level.  The  translation  of  tbe  responsibility 
of  instructing  introductory  programming  courses  to  tbe  secondary  level 
has  created  large  problem  for  secondary  instructors  who  have  little 
formal  training  in  tbe  computer  science  discipline.  This  report  is  the 
result  of  tbe  efforts  by  tbe  author  to  develop  a  course  to  teach  Intro- 
ductory students  to  solve  formal   analytic  computer   science   problems. 

The  report  defines  a  problem  domain  in  which  tbe  students  will  be 
asked  to  solve  formal  analytic  problems.  This  problem  domain  consists 
of  a  physical  processing  configuration  and  the  necessary  abstract  ana- 
lytic components  to  solve  problems  within  the  physical  processing  con- 
figuration. Next  the  report  defines  an  analytic  problem  solving  process 
which  is  used  to  completely  specify  tbe  solution  to  formal  analytic 
problems  within  the  defined  problem  domain.  This  process  includes  tbe 
specification  of  the  pre-  and  postcondition  of  tbe  physical  processing 
configuration  and  then  the  design  and  implementation  of  tbe  actions  to 
perform  the  translation  from  pre-  to  postcondition  into  a  high  level 
language. 

Lastly,  the  report  defines  a  possible  implementation  of  a  course 
which  concentrates  on  illustration  and  development  of  complete  solu- 
tions to  formal  analytic  problems  in  computer  science,  Tbe  course 
defined  in  this  paper  has  been  implemented  at  the  secondary  level  and 
for  two  semesters  at  Kansas  State  Onlversity  in  tbe  CS200  language 
labs. 


